先说索引，这玩意儿用好了能起死回生。但很多人建索引就跟撒胡椒面似的，乱建一气。有个项目在建表时搞了二十多个索引，插入数据比蜗牛还慢。其实重点照顾where条件、join字段和order by列就行。复合索引的顺序特别讲究，得把区分度高的字段放前面。像状态字段这种就几类值的，建了索引也白搭。还有件事得提醒，隐式类型转换会让索引失效。有次排查个慢查询，发现varchar字段传了数字参数，索引直接罢工了。
执行计划一定要会看。explain命令是必备工具，关键看type列，最好能到range级别，all全表扫描就得警惕了。possible_keys和key对不上说明索引没选对。有回遇到个诡异情况，明明有合适索引，mysql偏不用。后来用force index强制走索引，查询从3秒降到0.1秒。不过这只是临时方案，终极手段还得用analyze table更新统计信息。
SQL写法里的门道更多。能不用select *就别用，需要的字段一个个列出来。有次把text字段去掉后，查询速度直接翻倍。连表查询时小表驱动大表是基本原则，但具体还得看索引情况。子查询尽量改写成join，不过mysql5.6之后对子查询优化了不少，有时候反而比join快。还有limit分页，大数据量时用id范围查询替代offset，性能提升不是一点半点。
函数处理是个隐藏杀手。在字段上用函数计算绝对要避免，有次看到where left(name,3)='abc'这种写法，全表扫描没商量。应该改成name like 'abc%'。计算操作尽量放在业务代码里，别丢给数据库。
表设计也得未雨绸缪。该分表时就分表，按时间分、按业务分都行。有张日志表三个月就上亿条，拆成月表后查询快多了。字段类型选最合适的，数字类型别用varchar存储，否则比较排序都吃亏。
最后说说习惯问题。写完SQL先看执行计划，养成条件反射。定期抓取慢查询日志，重点关注执行时间长的SQL。监控系统里设置好警报，有慢查询及时通知。数据库版本升级时留神优化器策略变化，有次mysql小版本升级导致某个关键查询变慢，回滚后才恢复正常。
总之调优是个系统工程，从索引、SQL到架构都得考虑。关键是要有排查思路，先监控再分析，改了之后看效果。记住没有万能药，不同场景解法不同。有时候简单调整下索引顺序就能解决大问题，这种成就感比中彩票还爽。