我们不能等着系统上线，慢 SQL 吃光数据库资源之后，再找出慢 SQL 来改进，那样就晚了。那么，怎样才能在开发阶段尽量避免写出慢 SQL 呢？
慢 SQL 对数据库的影响，是一个量变到质变的过程，对“量”的把握，就很重 要。作为一个合格的程序员，你需要对数据库的能力，有一个定量的认识。
一般一台MySQL极限处理能力，大概是：每秒1w条简单的SQL。简单的意思是：类似主键查询，不需要遍历很多记录的SQL。正常的系统不可能只要简单SQL，实际的TPS还要大打折扣。
每秒执行SQL数量在几百左右就已经非常繁忙了，即使CPU利用率和磁盘繁忙不是特别高。但是也需要给数据库减轻压力了。
从数据量上来说，如果遍历行数在百万以内，每秒在100次是安全的。
如果遍历行数在几百万时，一次查询最少几秒钟，就需要考虑了。
遍历行数在千万级以上，这个查询就不该出现在在线系统中。
同时建议，每个表的数据量最好小于千万级别。
如果数据库中的数据量就是很多，而且查询业务逻辑就需要遍历大量数据怎么办？
索引可以显著减少查询遍历数据的数量，所以提升 SQL 查询性能最有效的方式就是，让查询尽可能多的命中索引，但索引也是一把双刃剑，它在提升查询性能的同时，也会降低数据更新的性能。
在 MySQL 中使用执行计划也非常简单，只要在你的 SQL 语句前面加上 EXPLAIN 关键字，然后执行这个查询语句就可以了。
举个例子说明，比如有一个用户表，包含用户 ID、姓名、部门编号和状态这几个字段：
我们希望查询某个二级部门下的所有人，查询条件就是，部门代号以 00028 开头的所有人。下面这两个 SQL，他们的查询结果是一样的，都满足要求，但是，哪个查询性能更好呢？
我们分别查看一下这两个 SQL 的执行计划：