【PDF】高效Mysql的N个习惯-阿里巴巴技术文档

高效MySQL的N个习惯叶金荣-知数堂培训联合创始人MySQL如何保持高效运行?N个好习惯用更好的硬件-主频高，让每个SQL处理时间更快，减少等待-线程多，同时支持更多并发SQL,提高TPS同时-记得关闭NUMA并设置为最大性能模式云栖社区云栖社区用更好的硬件-主频高，内存读写速率更高，更高吞吐，更低时延-内存大，更多数据在内存中，减少直接磁盘读写，提高TPS用更好的硬件-通常来说，磁盘I/0是最大的瓶颈-如果是机械盘，一定要配阵列卡，以及阵列卡的CACHE&BBU-最好是选用SSD或者PCleSSD,iops可以提升成千上万倍会会云栖社区用更好的硬件-文件传输速率高，异地文件备份更快-主从数据复制数据传输时延更小-适合大数据量的分布式存储环境-老版本内核中，网络请求太高时会引发中断瓶颈，建议升级内核-多个网卡可以进行绑定，提高传输速率并能提高可用性让OS跑的更快-减少系统开销-避免潜在安全隐患让OS跑的更快-坚决不使用nfs-除非是基于SSD的高速网络分布式存储-用于备份场景除外-性能上不相互影响-提高安全性-必须混搭时要做好权限管理以及安全隔离THECOMPUTINGCONFERENCE品time>time>-zfs/btrfs比较小众-降低使用swap的概率-内核2.6.32-303及以上版本，慎重设置为0,可能引发OOMINFO:taskjbd/dm-0-8:389blockedformorethan120seconds."echo0>/proc/sys/kernel/hungtasktimeoutsecs"disablethismessage.INFO:taskflush-253:0:1324blockedformorethan120seconds.echo0>/proc/sys/kernel/hungtasktimeoutsecs"disablethismessage.-数据多次读写后可能更离散，有更多随机I/0-没有业务用途-数值呈连续增长，最好是自增-坚决不能选用CHAR/UUID等类型-够用前提下，越短越好-消耗更少的存储空间-需要进行排序时，消耗更少的内存空间-每行长度超过8KB时，就需要分裂data产生更多离散I/0一案例：一个100G的表拆分成4个表后，总大小仅25G-分别表示写入时间以及最后更新时间-业务上可能用不到，但是对日常运维管理则非常有用-可以用来判断哪些是可以归档的老数据，定期进行归档-用来做自定义的差异备份也很方便-InnoDB行锁是基于索引实现-如果没有索引，将会是灾难性的-基数(cardinality)低的字段一般没必要建立单列索引-字符型字段上建索引时优先采用部分索引(prefixindex)-优先多列联合索引(multicolumnindex),少用单列索引-避免潜在的类型隐式转换风险-避免个别条件失效时SQL语法错误-减少不必要的I/0-提高可以利用覆盖索引的几率-避免SQL注入风险-所有用户输入值都要做过滤-LIKE查询时，不要用%通配符最左前导(无法使用索引)-能UNIONALL就不要UNION(UNION需要去重，会产生临时表)-满足业务需求前提下尽量用innerjoin,让优化器自动选择驱动表-有时候优化器选择的驱动表未必是最优的，可以尝试手动调整糟糕的SQL____-关键业务SQL上线前，都要EXPLAIN确认其执行计划尽量想办法进行优化运维习惯好-适当的场景下可以采用TokuDB运维习惯好-绝大多数情况下鸡肋，最好关闭-QC锁是全局锁，每次更新QC的内存块锁代价高，出现Waitingfor-实例启动前设置querycachetype=0&querycachesize=0运维习惯好-MySQL5.6开始支持独立表空间-MySQL5.7还可以回收已经purge的表空间-事务及时提交，不要积压。并且默认打开autocommit=1运维习惯好运维习惯好-maxconnections,突发最大连接数的80%为宜，过大容易导致全-干掉超过N秒的SQL-干掉疑似注入SQL-干掉长时间不活跃的sleep连接其他好习惯-但不见得一定要用pt-osc-不要真的删除，而是先rena