我每 30 秒对 MySQL 数据库运行一次以下查询：
SELECT message.id FROM message WHERE userto='13689' AND tstampviewed IS NULL AND message.status != 'VOID';
它经常出现在我的慢查询日志中，但在我看来，它已经尽可能地优化了。
解释的结果：
SELECT_TYPE = 简单
表 = 消息
类型 = 参考
POSSIBLE_KEYS = userto,tst,stat
KEY = 用户
KEY_LEN = 53
REF = 常量
行 = 1
EXTRA =“在哪里使用”
键 userto、tst 和 stat 都是普通的 BTREE 索引，一个对应于查询的 where 子句中引用的每个 varchar 字段。这是一个有 300K 行的 MyISAM 表。用户确实一致地写入表，但读取的可能性更大（读取与写入的比率为 10/1）。数据库服务器是具有大量 CPU 和快速驱动器的 Windows 2008 Enterprise。
在过去的一个月里，我们不断收到 max_connection 错误，即使我将 max_connections 从 750 增加到 1500。一天几次，查询似乎挂起（我无法验证这一点，因为我无权访问该进程实时列表），1500个查询堆积在它后面并最大化连接。这显然会导致许多其他问题。
上述查询始终出现在慢查询日志中，尽管我认为它已尽可能优化。任何人都可以告诉我或者指出我解决这个问题的正确方向吗？
提前致谢。