mysql查询太慢怎么办 mysql查询慢的优化方案

mysqlexecutebatch效率慢mysqlexecutebatch效率慢
1. 数据查询过慢一般是索引问题,可能是因为选错索引,也可能是因为查询的行数太多 。
2.客户端和数据库连接数过小,会限制sql的查询并发数,增大连接数可以提升速度 。
3.innodb里会有一层内存buffer pool用于提升查询速度,命中率一般99%,如果低于这个值,可以考虑增大buffer pool的大?。?这样也可以提升速度 。
MySQL查询效率很慢的问题如何分析和解决MySQL 在崩溃恢复时,会遍历打开所有 ibd 文件的 header page 验证数据字典的准确性,如果 MySQL 中包含了大量表,这个校验过程就会比较耗时 。MySQL 下崩溃恢复确实和表数量有关,表总数越大,崩溃恢复时间越长 。另外磁盘 IOPS 也会影响崩溃恢复时间,像这里开发库的 HDD IOPS 较低 , 因此面对大量的表空间,校验速度就非常缓慢 。另外一个发现 , MySQL 8 下正常启用时居然也会进行表空间校验,而故障恢复时则会额外再进行一次表空间校验 , 等于校验了 2 遍 。不过 MySQL 8.0 里多了一个特性 , 即表数量超过 5W 时,会启用多线程扫描,加快表空间校验过程 。
如何跳过校验MySQL 5.7 下有方法可以跳过崩溃恢复时的表空间校验过程嘛?查阅了资料,方法主要有两种:
1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 , 那么 validate= false,即可以跳过表空间校验 。实际测试的时候设置 innodb_force_recovery =1,也就是强制恢复跳过坏页,就可以跳过校验,然后重启就是正常启动了 。通过这种临时方式可以避免崩溃恢复后非常耗时的表空间校验过程,快速启动 MySQL,个人目前暂时未发现有什么隐患 。2. 使用共享表空间替代独立表空间这样就不需要打开 N 个 ibd 文件了 , 只需要打开一个 ibdata 文件即可,大大节省了校验时间 。自从听了姜老师讲过使用共享表空间替代独立表空间解决 drop 大表时性能抖动的原理后,感觉共享表空间在很多业务环境下,反而更有优势 。
临时冒出另外一种解决想法 , 即用 GDB 调试崩溃恢复,通过临时修改 validate 变量值让 MySQL 跳过表空间验证过程,然后让 MySQL 正常关闭 , 重新启动就可以正常启动了 。但是实际测试发现,如果以 debug 模式运行,确实可以临时修改 validate 变量,跳过表空间验证过程,但是 debug 模式下代码运行效率大打折扣,反而耗时更长 。而以非 debug 模式运行,则无法修改 validate 变量,想法破灭 。
Mysql 查询速度慢怎么办问题
我们有一个 SQL,用于找到没有主键 / 唯一键的表,但是在 MySQL 5.7 上运行特别慢 , 怎么办?
实验
我们搭建一个 MySQL 5.7 的环境,此处省略搭建步骤 。
写个简单的脚本,制造一批带主键和不带主键的表:
执行一下脚本:
现在执行以下 SQL 看看效果:
...
执行了 16.80s,感觉是非常慢了 。
现在用一下 DBA 三板斧,看看执行计划:
感觉有点惨 , 由于 information_schema.columns 是元数据表,没有必要的统计信息 。
【mysql查询太慢怎么办 mysql查询慢的优化方案】那我们来 show warnings 看看 MySQL 改写后的 SQL:
我们格式化一下 SQL:
可以看到 MySQL 将
select from A where A.x not in (select x from B) //非关联子查询
转换成了
select from A where not exists (select 1 from B where B.x = a.x) //关联子查询
如果我们自己是 MySQL,在执行非关联子查询时,可以使用很简单的策略:
select from A where A.x not in (select x from B where ...) //非关联子查询:1. 扫描 B 表中的所有记录 , 找到满足条件的记录,存放在临时表 C 中,建好索引2. 扫描 A 表中的记录 , 与临时表 C 中的记录进行比对,直接在索引里比对 , 

推荐阅读