【发布时间】:2012-11-06 00:29:24
【问题描述】:
我每 30 秒针对 MySQL 数据库运行一次以下查询:
SELECT message.id FROM message WHERE userto='13689' AND tstampviewed IS NULL AND message.status != 'VOID';
它经常出现在我的慢查询日志中,但在我看来它已经尽可能地优化了。
EXPLAIN 的结果:
SELECT_TYPE = 简单
TABLE = 消息
TYPE = 参考
POSSIBLE_KEYS = userto,tst,stat
KEY = userto
KEY_LEN = 53
REF = 常量
行 = 1
EXTRA = "在哪里使用"
键 userto、tst 和 stat 都是普通的 BTREE 索引,一个对应于查询 where 子句中引用的每个 varchar 字段。这是一个有 300K 行的 MyISAM 表。用户确实一致地写入表,但读取的可能性更大(读取与写入的比率为 10/1)。数据库服务器是 Windows 2008 Enterprise,具有大量 CPU 和快速驱动器。
在过去的一个月里,我们不断收到 max_connection 错误,尽管我将 max_connections 从 750 增加到 1500。一天几次,查询似乎挂起(我无法验证这一点,因为我没有访问权限实时到进程列表),1500个查询堆积在它后面并最大化连接。这显然会导致许多其他问题。
上述查询始终出现在慢查询日志中,尽管我认为它已尽可能优化。谁能告诉我其他情况或指出正确的方向来解决这个问题?
提前致谢。
【问题讨论】:
-
您是否可能在 cron 作业中运行管理任务,例如
OPTIMIZE TABLE或ANALYZE TABLE?这些会停止其他查询,但不会显示在慢查询日志中。
标签: mysql optimization indexing