1.首先我们要了解一下次库是以写为主还是读为主：
通过show [session|global] status like '%Com_%'查询当前数据库的状态，session是当前连接的，global是自从上次数据库启动后的。默认不写是session
| Com_select | 2 |
| Com_insert | 0 |
| Com_update | 0 |
| Com_delete | 0 |
后面表示累加的执行次数，所有的存储引擎都可以进行累加
show [session|global] status like '%Innodb_rows_%'
+----------------------+-------+
| Variable_name | Value |
+----------------------+-------+
| Innodb_rows_deleted | 0 |
| Innodb_rows_inserted | 7 |
| Innodb_rows_read | 6 |
| Innodb_rows_updated | 0 |
+----------------------+-------+
这个是只针对innodb引擎的。
通过上述结果我们就能大致知道该库是读为主还是写为主了，更新操作的commit和rollback计数都会加1
Com_commit和Com_rollback中，后者很频繁可能是应用有问题
2.其次我们要定位效率低的sql语句，可以用以下两种方式进行：
（1）通过慢查询日志：5.6中是slow_query_log_file中查看，缺点是：这个是只有在查询结束后彩记录，所以在应用向你反映效率问题时慢查询日志并不能及时反馈，也许执行的语句还没写进去。
（2）针对上面问题，可以用 show processlist命令查看MySQL进行的线程，包括状态、是否锁表等。可以实时查看SQL执行情况，同时对一些锁表操作进行优化
3.通过explain分析效率低下的 sql执行计划：
当通过上述方式找到效率不高的sql语句后，通过explain或者desc可以分析效率低下的sql的执行计划
4.根据分析得出的问题解决效率低下问题：
通过上述几步就可以得出问题所在，比如进行全表扫描，那么我们可以通过建立索引提高效率
