将文件拖动至此

SQL 上传 ( 0 ) x -

页面相关设置 点击以滚动到页面顶部
按 Ctrl+Enter 键执行查询 按 Enter 执行查询
递增排序
递减排序
命令：
调试 SQL
数量
运行顺序
用时
排序条件：
联合查询
不使用联合查询
崩溃 扩展 显示跟踪 隐藏跟踪 数量 用时
书签
刷新
添加
没有书签
添加书签
选项
恢复默认





崩溃 扩展 重新查询 编辑 解析 性能分析 书签 查询失败 数据库 : 查询时间 :

建议系统

可能存在的性能问题

问题：
long_query_time 当前设为 10 秒或更长，因此超过 10 秒的查询才被记为慢查询。
建议：
建议根据您的环境将 long_query_time 调短。通常建议设为 1-5 秒。
现状：
long_query_time 当前被设为 10 秒。
使用的变量/公式：
long_query_time
检验：
value >= 10
问题：
慢查询记录已禁用。
建议：
请将 slow_query_log 设为 'ON' 来启用慢查询记录。这将有助于解决查询问题。
现状：
slow_query_log 被设为 'OFF'
使用的变量/公式：
slow_query_log
检验：
value == 'OFF'
问题：
大量行被排序。
建议：
大量行排序不是什么错误，但您应确保需要大量排序的查询在 ORDER BY 中使用索引字段，这将使排序加快。
现状：
行排序率: 41.75 每分钟
使用的变量/公式：
Sort_rows / Uptime
检验：
value * 60 >= 1
问题：
有太多的联合查询未使用索引。
建议：
这意味着联合查询使用全表扫描。给联合条件所用的字段增加索引将极大提高查询速度。
现状：
表联合率: 1.22 每秒，该值应低于 1 每小时
使用的变量/公式：
(Select_range_check + Select_scan + Select_full_join) / Uptime
检验：
value * 60 * 60 > 1
问题：
读取第一个索引入口比例过高。
建议：
这通常说明频繁的全索引扫描。全索引扫描虽然比全表扫描快，但在大表中仍然需要一定 CPU 周期，如果这些表有或有过大量 UPDATE 和 DELETE，运行 'OPTIMIZE TABLE' 可减少全索引扫描的次数以及提高速度。其它会减少全索引扫描的是重写查询。
现状：
索引扫描率: 2.24 每分钟，该值应低于 1 每小时
使用的变量/公式：
Handler_read_first / Uptime
检验：
value * 60 * 60 > 1
问题：
从固定位置读取数据的比例过高。
建议：
这说明很多查询需要结果排序且/或执行一次全表扫描，包括无索引的联合查询。请在合适的地方添加索引。
现状：
固定位置读取率: 41.74 每分钟，该值应低于 1 每小时
使用的变量/公式：
Handler_read_rnd / Uptime
检验：
value * 60 * 60 > 1
问题：
读取下一行的比例过高。
建议：
这说明很多查询都需要全表扫描。请在合适的地方添加索引。
现状：
下一行读取率: 1919.25 每秒，该值应低于 1 每小时
使用的变量/公式：
Handler_read_rnd_next / Uptime
检验：
value * 60 * 60 > 1
问题：
很多临时表被创建在磁盘上而非内存中。
建议：
增加 max_heap_table_size 和 tmp_table_size 可能会有帮助。但有些临时表总是会写入硬盘，和这些变量无关。要避免这些，您需要重写您的查询来避免 MySQL 文档中所提到的这些条件 (临时表内: 具有 BLOB 或 TEXT 字段或具有大于 512 字节的字段)
现状：
临时表硬盘写入率: 19.13 每分钟，该值应低于 1 每小时
使用的变量/公式：
Created_tmp_disk_tables / Uptime
检验：
value * 60 * 60 > 1
问题：
MyISAM 索引缓存 % 使用率低。
建议：
您可能需要减小 key_buffer_size 的大小，重新检查您的表是否删除了索引或检查查询期望使用的索引。
现状：
最大 % MyISAM 索引缓存从未使用: 0%，该值应高于 95%
使用的变量/公式：
Key_blocks_used * key_cache_block_size / key_buffer_size * 100
检验：
value < 95
问题：
太多连接已中止。
建议：
连接通常因为无法被授权而中止。这篇文章对您追踪来源可能有所帮助。
现状：
11% 的连接已中止。该值应低于 1%
使用的变量/公式：
Aborted_connects / Connections * 100
检验：
value > 1
问题：
太多连接已中止。
建议：
连接通常因为无法被授权而中止。这篇文章对您追踪来源可能有所帮助。
现状：
已中止连接率为 33.81 每小时，该值应低于 1 每小时
使用的变量/公式：
Aborted_connects / Uptime
检验：
value * 60 * 60 > 1
问题：
你的 InnoDB 缓冲池相当小。
建议：
InnoDB缓冲池对InnoDB表的性能有着深远的影响。将所有剩余内存分配给此缓冲区。对于仅使用InnoDB作为存储引擎并且没有其他服务（例如Web服务器）运行的数据库服务器，您可以将其设置为高达可用内存的80%。如果不是这种情况，则需要仔细评估其他服务和非InnoDB-Tables的内存消耗，并相应地设置此变量。如果设置得太高，系统将开始使用交换内存，这会显着降低性能。另请参见这篇文章
现状：
您当前的 InnoDB 缓冲池使用了内存的 25.02612665942% 。此规则在您分配少于 60% 时被触发，然而这也可能因为您没有太多 InnoDB 表所以这样足够或者服务器上还运行了其它服务。
使用的变量/公式：
innodb_buffer_pool_size / system_memory * 100
检验：
value < 60
问题：
查询缓存没有启用。
建议：
若正确设置查询缓存将带来性能上的极大提升。您可以通过设置 query_cache_size 为 2 位数的 MB 值和设置 query_cache_type 为 'ON'。注意: 若您正在使用 memcached，请忽略此建议。
现状：
query_cache_size 被设为 0 或 query_cache_type 被设为 'OFF'
使用的变量/公式：
query_cache_size
检验：
value == 0 || query_cache_type == 'OFF' || query_cache_type == '0'