导读
关于 lower_case_table_names 选项的设置的建议是怎样的呢？
问题由来
我个人认为，纠结于这个选项设置源于有些项目是从ORACLE或SQL Server迁移过来，在这两个数据库系统中，都无需关心数据表的大小写。而在MySQL中，默认是要区分大小写的(因为Unix/Linux文件系统是区分文件名大小写的)，除非在windows系统下(windows系统是不区分大小写的)。
老叶的建议
我在公司制定的规范是要求默认设置 lower_case_table_names=0
的，也就是区分大小写。那么问题来了，如果是从ORACLE或SQL Server迁移到MYSQL的应用应该怎么处理呢？
我的建议是：
导读
利用MySQL的event来自动维护表分区。
我们去年就开始把zabbix数据库改成用TokuDB来支撑，并且启用了表分区（详情见：迁移Zabbix数据库到TokuDB）。这样做的好处很明显，较早的历史数据可以通过删除分区快速废弃掉。要知道，zabbix数据表默认是没有针对时间字段创建索引的，因此如果执行删除的SQL命令，其效率会很差，而直接删除分区就快多了。
先看history表的分区规则：
CREATE TABLE history (
itemid bigint(20) unsigned NOT NULL,
clock int(11) NOT NULL DEFAULT '0',
value double(16,4) NOT NULL DEFAULT '0.0000',
ns int(11) NOT NULL DEFAULT '0',
KEY history_1 (itemid,clock)
) ENGINE=TokuDB DEFAULT CHARSET=utf8 ROW_FORMAT=TOKUDB_QUICKLZ
PARTITION BY RANGE (clock)
(PARTITION …导读
MySQL主从复制环境中，如何才能保证主从数据的一致性呢？
关于主从复制
现在常用的MySQL高可用方案，十有八九是基于 MySQL的主从复制（replication）来设计的，包括常规的一主一从、双主模式，或者半同步复制（semi-sync replication）。
我们常常把MySQL replication说成是MySQL同步（sync），但事实上这个过程是异步（async）的。大概过程是这样的：
步骤1和步骤3之间是异步进行的，无需等待确认各自的状态，所以说MySQL replication是异步的。
MySQL semi-sync replication在之前的基础上做了加强完善，整个流程变成了下面这样：
导读
在MySQL里，主键索引和辅助索引分别是什么意思，有什么区别？
上次的分享我们介绍了聚集索引和非聚集索引的区别，本次我们继续介绍主键索引和辅助索引的区别。
1、主键索引
主键索引，简称主键，原文是PRIMARY KEY，由一个或多个列组成，用于唯一性标识数据表中的某一条记录。一个表可以没有主键，但最多只能有一个主键，并且主键值不能包含NULL。
在MySQL中，InnoDB数据表的主键设计我们通常遵循几个原则：
这么做的好处有几点：
导读
当磁盘空间爆满后，MySQL会发生什么事呢？又应该怎么应对？
会发生什么事
当磁盘空间写满了之后，MySQL是无法再写入任何数据的，包括对表数据的写入，以及binlog、binlog-index等文件。
当然了，因为InnoDB是可以把脏数据先放在内存里，所以不会立刻表现出来无法写入，除非开启了binlog，写入请求才会被阻塞。
当MySQL检测到磁盘空间满了，它会：
应该怎么办
…
[获取更多]导读
在MySQL复制中，如何忽略slave节点上发生的主键冲突、数据不存在等错误。
在MySQL复制中，如果slave节点上遇到错误，比如数据不存在或者主键冲突等错误时，想要忽略这些错误，可以采用以下几种方法：
1、未启用GTID模式时
只需通过设定 SQL_SLAVE_SKIP_COUNTER 的值，即可忽略一些复制事件。例如：
#需要先关闭SLAVE服务
root@imysql.com [test]> STOP SLAVE;
#忽略N个事件（event），通常一个SQL是一个事件
root@imysql.com [test]> SET SQL_SLAVE_SKIP_COUNTER=N;
#再次启动SLAVE服务
root@imysql.com [test]> START SLAVE;
2、启用GTID模式时
启用GTID，想要忽略某些错误事件就稍微麻烦一点点了。
首先，我们需要先查看当前SLAVE复制的进度：
mysql> SHOW SLAVE STATUS\G …
[获取更多]有时候，我们会遇到类似下面的报错信息：
..... [ERROR] /usr/local/mysql/bin/mysqld: Can't open file: './yejr/access.frm' (errno: 24) [ERROR] /usr/local/mysql/bin/mysqld: Can't open file: './yejr/accesslog.frm' (errno: 24) ...... [ERROR] Error in accept: Too many open files ....
提示信息很明显，打开文件数达到上限了，需要提高上限，或者释放部分已打开的表文件描述符。
在MySQL中，有几个地方会存在文件描述符限制：
1、在Server层，整个mysqld实例打开文件总数超过用户进程级的文件数限制，需要检查内核 fs.file-max 限制、进程级限制 ulimit -n 及MySQL中的 open-files-limit 选项，是否有某一个超限了。任何一个条件超限了，就会抛出错误。 …[获取更多]
大多数MySQL规范在网上也都能找得到相关的分享，在这里要分享的是老叶个人认为比较重要的，或者容易被忽视的，以及容易被混淆的一些地方。
1、默认使用InnoDB引擎
【老叶观点】已多次呼吁过了，InnoDB适用于几乎99%的MySQL应用场景，而且在MySQL
5.7的系统表都改成InnoDB了，还有什么理由再死守MyISAM呢。
此外，频繁读写的InnoDB表，一定要使用具有自增/顺序特征的整型作为显式主键。
【参考】：[MySQL FAQ]系列 — 为什么InnoDB表要建议用自增列做主键。
2、字符集选择utf-8
…
本文是基于MySQL-5.7.7-rc版本，未来可能 还会发生更多变化。
1、SQL MODE变化
a. 默认启用 STRICT_TRANS_TABLES 模式；
b. 对 ONLY_FULL_GROUP_BY 模式实现了更复杂的特性支持，并且也被默认启用；
c. 其他被默认启用的sql mode还有 NO_ENGINE_SUBSTITUTION；
【iMySQL建议】
对广大MySQL使用者而言，以往不是那么严格的模式还是很方便的，在5.7版本下可能会觉得略为不适，慢慢习惯吧。比如向一个20字符长度的VARCHAR列写入30个字符，在以前会自动截断并给个提示告警，而在5.7版本下，则直接抛出错误了。个人认为这倒是一个好的做法，避免各种奇葩的写法。
【新特性实践】
-- 查看默认的 sql_mode [yejr@imysql.com]> select @@sql_mode; +-----------------------------------------------------------------------------------+ | @@sql_mode | …[获取更多]
利用MySQL的PROFILE功能，我们可以很方便的查看一个SQL具体的执行代价是怎样的，尤其是可以分析它的最大瓶颈在哪里。目前PROFILE功能可提供除了内存以外的其他资源消耗统计，例如CPU、I/O、CONTEXT、SWAP等。
PROFILE功能只能在SESSION级别使用，还做不到像SQL Server那样可以全局开启，收集一段时间后再关闭，这点有待改进。关于PROFILE的具体用法大家可以查看手册 13.7.5.31 SHOW PROFILE Syntax，这里不细说。
大部分情况下，PROFILE的结果我们主要关注两列：Status、Duration，前者表示的是PROFILE里的状态，它和PROCESSLIST的状态基本是一致的，后者是该状态的耗时。因此，我们最主要的是关注处于哪个状态耗时最久，这些状态中，哪些可以进一步优化。 …
[获取更多]