假如没有索引的话，explain会显示返回查询全表的数据自然会很慢了。假如用到了索引的话，可以快速的找到需要查询的区间里的数据，往往需要查询的数据量是全表的1/100，1/1000，那么这时候花费的时间就是1/100，1/1000了。
从网站建设到定制行业解决方案，为提供网站建设、网站设计服务体系，各种行业企业客户提供网站建设解决方案，助力业务快速发展。创新互联将不断加快创新步伐，提供优质的建站服务。
DB重启之后要预热的，因为内存中缓存的数据都被清空了，需要一段时间的预热才能提高响应速度。DB确实很慢很慢，查磁盘负载，是不是磁盘读写IO已经满了。
数据文件是和（主键）索引绑在一起的（表数据文件本身就是按B+Tree组织的一个索引结构），必须要有主键，通过主键索引效率很高。但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。
因为是记录url其字段值很长，在MySQL数据库里为长字段添加索引后查询速度是有可能变慢的。建议使用前缀索引试一试，看看能否改善。
1、MySQL 下崩溃恢复确实和表数量有关，表总数越大，崩溃恢复时间越长。另外磁盘 IOPS 也会影响崩溃恢复时间，像这里开发库的 HDD IOPS 较低，因此面对大量的表空间，校验速度就非常缓慢。
2、问题分析考虑到可能是程序性能问题后，我使用了xdebug的性能日志功能输出程序运行日志后发现连接mysql的函数时间居然用掉了接近95%的执行时间。
3、两种可能 第一是 机器本身有太多的进程或者服务导致cpu占有两次太高 或者硬盘老化 冗余数据较多 查询结果缓慢 第二还有可能是 mysql的设置或者sql语句本身的问题了 看是哪方面的。
硬盘读写速度会影响输入库的写入速度的，另外看看你的mysql是不是加了好多索引，或者是不是远端数据库。。
查看一下是否修改成功，这个应该就不用重启mysql了，重启反而失效了。
你打开那个.sql文件看过没有，不仅仅只有数据，还包含表结构。在导入的时候先是创建表，然后再插入数据的。
1、MySQL 默认使用的是 glibc 的 ptmalloc 作为内存分配器。内存分配器采用的是内存池的管理方式，处在用户程序层和内核层之间，它响应用户的分配请求，向操作系统申请内存，然后将其返回给用户程序。
2、检查系统的状态 通过操作系统的一些工具检查系统的状态，比如CPU、内存、交换、磁盘的利用率，根据经验或与系统正常时的状态相比对，有时系统表面上看起来看空闲，这也可能不是一个正常的状态，因为cpu可能正等待IO的完成。
3、第三个诊断思路是外部的需求改造，我在这里引用了一篇文档，这篇文档是MySQL的guan 方文档中的一章，这一章叫Examples of Common Queries，文档中介绍了常规的SQL怎么写， 给出了一些例子。文章的链接二维码在slide上。
问题分析考虑到可能是程序性能问题后，我使用了xdebug的性能日志功能输出程序运行日志后发现连接mysql的函数时间居然用掉了接近95%的执行时间。
MySQL 下崩溃恢复确实和表数量有关，表总数越大，崩溃恢复时间越长。另外磁盘 IOPS 也会影响崩溃恢复时间，像这里开发库的 HDD IOPS 较低，因此面对大量的表空间，校验速度就非常缓慢。
看下延时。如果延时正常的话，然后查询下连接数，检查是不是创建了大量连接。再没有问题就尝试sqlplus直连。正常情况数据库主机通信不是很大，一般是程序中有大量创建连接引起的。
MySQL数据库有几个配置选项可以帮助我们及时捕获低效SQL语句1，slow_query_log这个参数设置为ON，可以捕获执行时间超过一定数值的SQL语句。2，long_query_time当SQL语句执行时间超过此数值时，就会被记录到日志中，建议设置为1或者更短。
