在实际应用场景中，我们一般都使用innodb作为默认的存储引擎，除了支持事务和行锁是比较重要的两个原因外，其实myisam在实际应用
摘要： 这篇文章总结了工作中用到mysql的一些常见问题，，解决方案；合适的使用场景和优化方案。
目录：
存储引擎的选择：myisam vs innodb
使用与优化
db的优化
sql的优化
应用的优化
简单故障排查技巧
慢查询排查
lock情况排查
slave延时排查
监控
内置命令
外部监控
简单说说mysql高可用
最后
存储引擎的选择：myisam vs innodb
myisam：支持全文索引；使用表级锁；读并发性能好。
innodb：支持事务和外键；使用行级锁；写并发性能较好。
在实际应用场景中，我们一般都使用innodb作为默认的存储引擎，除了支持事务和行锁是比较重要的两个原因外，其实myisam在实际应用场景中意义也不大，看看下面几个原因：
全文索引完全可以（也应该）用第三方软件来替代，比如：sphinx；
读性能高的特点完全可以用前端缓存来替代，这已经是互联网应用的标配了；
表级锁在并发写操作多时会严重影响读操作（写优先）；
使用与优化 
db的优化建立合适的索引：
尽量让所有查询都走索引，这个效果是很明显的。
表空间优化：
在删除或更新比较频繁的表上，如果包含varchar,text之类的字段，需要定期地执行表空间优化,optimaize table xxx，整理磁盘碎片，回收表数据和索引数据占用的空闲空间;
配置参数优化：
innodb_buffer_pool_size  innodb表数据和索引数据的内存缓冲大小，很关键，可以有效减少磁盘io。
innodb_flush_log_at_trx_commit 决定事务日志怎么记录，这个对性能提升也很关键，在线下批量写数据时可以考虑设置为0.或者写操作频繁但允许故障时丢失极少量数据的情况也可以考虑。
query_cache 这个参数有些微妙，因为query cache在数据表中有任何数据修改时就会失效，对于写操作频繁的表来说，有可能还会降低性能。对于读操作为主的表来说，效果还是很明显的，但是通常场景下我们都依赖于前端缓存，所以对于这个参数的设置来说，还要看具体业务场景。
max_connections 控制并发连接数，不能太大，否则后果很严重。
拆分与扩容：
库拆分：一般是把同一实例上的数据库分到多个实例上来分担压力（这种比较简单，做一份复制，应用端改个ip就行），或者是把一个库里面的部分表单独放到另一个实例库中（这种比较麻烦，需要应用端配合修改程序）。
表拆分：也分两种，一种是把一些字段的拆出到新表里，比如按业务分，或者是像text之类的大字段拆分。另一种是表记录数太大，超出了单表承受能力，需要水平扩展到多张表。表拆分比较麻烦，都需要应用端配合修改程序。
sql的优化 
应用的优化更多详情见请继续阅读下一页的精彩内容：
相关阅读：
mysql优化案例分析
mysql优化：可配置选项的wait_for_read
centos系统mysql优化详解