MySQL的核心只允许在给定的时间段（例如每秒）中借由物理过程来运行一定数量的SQL语句。无论你的计算机有多么强力，这一物理过程始终存在运算上限。如果你能够将SQL语句中那些不具备关键性或必要性的部分精简掉，那么与此同时，真正重要的SQL语句也将自动得到优先处理。当然这也将带来其它一些连锁反应，但只是简单数学范畴内的小问题。总之，要运行更多SQL指令，首先对你的指令进行精简。
在此我们列举一个简单的例子，通过mk-query-digest工具对TCP/IP数据包进行分析并输出结果。
# Rank Query ID Response time Calls R/Call Apdx V/M Item
# ==== ================== ============= ===== ====== ==== ===== ==========
# 1 0xD631CB919867DB50 0.0436 47.3% 92 0.0005 1.00 0.00 SELECT TTDOD
# 2 0x04FE01C5B31FD305 0.0258 27.9% 329 0.0001 1.00 0.00 ADMIN PING
# 3 0x93321857BCD8E771 0.0229 24.8% 36 0.0006 1.00 0.00 SELECT TTD
其中存在很多问题，包括SQL的一次一行(RAT)特性，不过在这里我们暂不讨论ping过多的问题。首先让我们看看第一个语句。
SELECT `Date` FROM TTDOD WHERE ID = 9999;
表面上看这个查询指令已经够简洁了，但让我们再看看列表。
mysql> select count(*) from TTDOD;
+----------+
| count(*) |
+----------+
| 0 |
+----------+
在这种情况下，因为当前列表是空的，所以查询指令将不会返回任何内容。当然这一点在未来可能会发生变化，但就目前来看这更多的是一种在简单数据管理中的异常处理状态，因为该列表中很少会存在内容。而建立一种有针对性的解决方案来通知该应用程序，可以完全避免这类不必要的查询行为。
以上只是个运行时间不足2秒的参考实例，而清除第一个查询指令也已经使整体查询时耗降低了20%。不管这仅仅是个典型的载入过程抑或是批处理中的并行载入过程，原理都是共通的。而且毫无疑问，在接下来的查询指令中，我们的精简工作还大有可为。
