大多半MySQL样板在网上也都能找获得联系的分享，在这边要分享的是老叶私人以为对照紧要的，或许轻易被忽略的，以及轻易被混淆的一些场合。
1、默许应用InnoDB引擎已屡屡倡议过了，InnoDB合用于险些99%的MySQL运用处景，况且在MySQL5.7的系统表都改为InnoDB了，再有甚么来由再固守MyISAM呢。
其余，频频读写的InnoDB表，确定要使器械有自增/挨次特点的整型做为显式主键。
固然了，也不是说MyISAM就一无可取，比方老叶之前就把MyISAM用于且自导数据数据（把数据导入MyISAM，一番解决后再入到InnoDB表）、或许一些非常的数据统计类场景用MyISAM（大数据量下MyISAM全表挨次读取比InnoDB有显然上风）也许对照符合。前提是，你得特别明了MyISAM引擎的上风在那边。
：[MySQLFAQ]系列—为甚么InnoDB表要发起用自增列做主键。
2、InnoDB表行纪录物理长度不超出8KB
InnoDB的datapag默许是16KB，基于B+Tr的特色，一个datapag中需求起码储备2笔纪录。因而，当实践储备长度超出8KB（尤为是TEXT/BLOB列）的大列（largcolumn）时会引发“pag-ovrflow储备”，好似ORACLE中的“行迁徙”。
因而，倘使务必应用大列（尤为是TEXT/BLOB表率）且读写频频的话，则最佳把这些列拆分到子表中，不要和主表放在一同储备。倘使不太频频，也许琢磨连续保存在主表中。
固然了，倘使将innodb_pag_siz选项修正为8KB，那末行纪录物理长度发起不超出4KB。
：[MySQL优化案例]系列—优化InnoDB表BLOB列的储备效率。
3、能否应用表分区（partition）在一些应用表分区后显然也许晋升机能或许运维便捷性的场景下，照样发起应用表分区。
比方老叶就在zabbix的数据库采纳TokuDB引擎的前提下，又依照时光维度应用了分区。如此的长处是保证zabbix每每运用不遭到影响前提下，便利治理员例行省略之前数据，只要要省略响应分区便可，不需再施行一个特别慢的DELETE而影响团体机能。
固然了，应用表分区也许不利于物理扩充，比方大数据量下想要做哈希程度拆分，这个就见仁见智了，倘使你的营业场景下应用表分区更有长处，就安心斗胆的用吧。该停止拆分就用拆分谋划，不要连续抱着表分区谋划不放。
参考：迁徙Zabbix数据库到TokuDB。
4、能否应用储备流程、触发器在一些符合的场景下，用储备流程、触发器也齐备没题目。
咱们之前即是操纵储备结尾嬉戏营业逻辑解决，机能上不是题目，况且一旦需求有变动，只要修正储备流程，变动价格很低。咱们还操纵触发器保护一个频频革新的表，对这个表的全部变动都将部份字段同步革新到另一个表中（好似物化视图的变相完结），也不存在机能题目。
有同业以为储备流程和触发器的运用也许会致使产生锁等候、死锁时排究诘题上的猜忌。嗯，这个是有这个也许性，不过如真的产生时，依照那时现场纪录的SQL反核对应的储备流程或触发器，该当也不是难事，只不过请求DBA对线上营业处境更要了解于胸了。
总的来讲，不要把MySQL的储备流程和触发器视为大水猛兽，用好的话，没有题目的，真碰到题目了再优化也不迟。其它，MySQL由于没有物化视图，因而视图能不必就只管少用吧。
5、筛选符合的表率除了罕见的发起外，再有其余几个重心：
5.1、用INTUNSIGNED储备IPV4地点，用INET_ATON()、INET_NTOA()停止变换，根本上没需求应用CHAR(15)来储备。
5.2、列举表率也许应用ENUM，ENUM的内部储备机制是采纳TINYINT或SMALLINT（并非CHAR/VARCHAR），机能一点都不差，记着万万别用CHAR/VARCHAR来储备列举数据。
5.3、还个早前一向在宣传的“学问性误导”，发起用TIMESTAMP庖代DATETIME。原本从5.6最先，发起优先筛选DATETIME储备日期时光，由于它的可用界限比TIMESTAMP更大，物理储备上仅比TIMESTAMP多1个字节，团体机能上的损失并不大。
5.4、全部字段界说中，默许都加之NOTNULL抑制，除非务必为NULL（但我也想不出来甚么场景下务需求在数据库中储备NULL值，也许用0来示意）。在对该字段停止COUNT()统计时，统计了局更精确（值为NULL的不会被COUNT统计出来），或许施行WHEREcolumnISNULL检索时，也也许神速返回了局。
5.5、杜绝直接SELECT*读取统统字段，当表中存在TEXT/BLOB大列的时光就会是灾祸了。也许从来不需求读取这些列，但由于偷懒写成SELECT*致使内存buffrpool被这些“废料”数据把真实需求缓冲起来的热门数据给洗出去了。
响应地，在写INSERT时，也要写上相对应的字段列表。
请求在SQL中写明了每个字段的紧要意义还在于，当营业需求表DDL产生革新后，倘使不写明了字段，也许会致使旧营业代码不行用，这个就折腾大发了。
6、对于索引除了罕见的发起外，再有几个重心：
6.1、超出20个长度的字符串列，最佳建立前缀索引而非整列索引（比方：ALTERTABLEt1ADDINDEX(usr(20))），也许有用升高索引操纵率，不过它的瑕玷是对这个列排序时用不到前缀索引。前缀索引的长度也许基于对该字段的统计得出，正常略大于均匀长度一点就也许了。
6.2、按时用pt-duplicat-ky-chckr器械检讨并省略冗余的索引。比方indxidx1(a,b)索引曾经涵盖了indxidx2(a)，就也许省略idx2索引了。
6.3、有多字段联合索引时，WHERE中过滤前提的字段挨次无需和索引一致，但倘使有排序、分组则就务必一致了。
例倘有联合索引idx1(a,b,c)，那末上面的SQL均也许完好用到索引：
SELECT...WHEREb=?ANDc=?ANDa=?;--留意到，WHERE中字段挨次并没有和索引字段挨次一致
SELECT...WHEREb=?ANDa=?ANDc=?;
SELECT...WHEREa=?ANDbIN(?,?)ANDc=?;
SELECT...WHEREa=?ANDb=?ORDERBYc;
SELECT...WHEREa=?ANDbIN(?,?)ORDERBYc;
SELECT...WHEREa=?ORDERBYb,c;
SELECT...ORDERBYa,b,c;--可操纵联合索引结尾排序
而上面几个SQL则只可用到部份索引：
SELECT...WHEREb=?ANDa=?;--只可用到(a,b)部份
SELECT...WHEREaIN(?,?)ANDb=?;--只可用到(a,b)部份
SELECT...WHEREa=?ANDc=?;--只可用到(a)部份
SELECT...WHEREa=?ANDbIN(?,?);--只可用到(a,b)部份
SELECT...WHERE(aBETWEEN?AND?)ANDb=?;--只可用到(a)部份，留意BETWEEN和IN的差别
SELECT...WHEREa=?AND(bBETWEEN?AND?)ANDc=?;--只可用到(a,b)部份
上面的几个SQL齐备用不到该索引：
SELECT...WHEREb=?;
SELECT...WHEREb=?ANDc=?;
SELECT...WHEREb=?ANDc=?;
SELECT...ORDERBYb;
SELECT...ORDERBYb,a;
从上头的几个例子就可以看的出来，往常强调的WHERE前提字段挨次要和索引挨次一致才具应用索引的“学问性误导”无需严厉遵循。
其余，有些时光盘查优化器指定的索引或施行谋划也许并不是最优的，也许手工指定最优索引，或许修正sssion级的optimizr_switch选项，阻塞某些致使功效反而更差的个性（比方indxmrg每每是善事，但也碰到过用上indxmrg后反而更差的，这时光要末强迫指定此中一个索引，要末也许且自阻塞indxmrg个性）。
7、其余7.1、哪怕是基于索引的前提过滤，倘使优化器意识到统共需求扫描的数据量超出30%时（ORACLE里好像是20%，MySQL当前是30%，没准之后会调动），就会直接改观施行谋划为全表扫描，不再应用索引。
7.2、多表JOIN时，要把过滤性最大（不确定是数据量最小哦，而是只加了WHERE前提后过滤性最大的阿谁）的表选为启动表。其余，倘使JOIN之后有排序，排序字段确定要属于启动表，才具操纵启动表上的索引结尾排序。
7.3、绝大多半情景下，排序的众人每每要来的更高，因而倘使看到施行谋划中有Usingfilsort，优先建立排序索引吧。
7.4、操纵pt-qury-digst按时解析slowqurylog，并联合BoxAnmomtr建设slowqurylog解析及优化系统。
：[MySQLFAQ]系列—EXPLAIN了局中哪些消息要引发