13518219792
实际测试的时候设置 innodb_force_recovery =1，也就是强制恢复跳过坏页，就可以跳过校验，然后重启就是正常启动了。通过这种临时方式可以避免崩溃恢复后非常耗时的表空间校验过程，快速启动 MySQL，个人目前暂时未发现有什么隐患。
我们提供的服务有：做网站、网站制作、微信公众号开发、网站优化、网站认证、芜湖ssl等。为1000+企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务，是有科学管理、有技术的芜湖网站制作公司
InnoDB是聚集索引，使用B+Tree作为索引结构，数据文件是和（主键）索引绑在一起的（表数据文件本身就是按B+Tree组织的一个索引结构），必须要有主键，通过主键索引效率很高。
时间的快慢主要由索引决定，在索引都最优化的情况下才与数据量有关。视图不可能明显加快的查询速度，只是编程方便而已。
我们有一个 SQL，用于找到没有主键 / 唯一键的表，但是在 MySQL 7 上运行特别慢，怎么办？实验 我们搭建一个 MySQL 7 的环境，此处省略搭建步骤。
常见的内存分配器包括：ptmalloc(Glibc)、tcmalloc(Google)、jemalloc(FreeBSD)。MySQL 默认使用的是 glibc 的 ptmalloc 作为内存分配器。
\ 对于 information_schema 中的元数据表，执行计划不能提供有效信息。\ 通过查看 MySQL 改写后的 SQL，我们猜测了优化器发生了误判。\ 我们增加了 hint，指导 MySQL 正确进行优化判断。
配置 innodb_force_recovery可以使 srv_force_recovery ！= 0 ，那么 validate = false，即可以跳过表空间校验。
这是一个慢查询日志的展示工具，能够帮助 DBA 或者开发人员分析数据库的性能问题，给出全面的数据摆脱直接查看 slow-log。
这个参数设置为ON，可以捕获到所有未使用索引的SQL语句，尽管这个SQL语句有可能执行得挺快。
1、查看建立索引前面的返回的结果。假如没有索引的话，explain会显示返回查询全表的数据自然会很慢了。
2、\ 对于 information_schema 中的元数据表，执行计划不能提供有效信息。\ 通过查看 MySQL 改写后的 SQL，我们猜测了优化器发生了误判。\ 我们增加了 hint，指导 MySQL 正确进行优化判断。
3、在一些数据库服务器上，索引可能失效或者因为频繁操作而使得读取效率降低，如果一个使用索引的查询不明不白地慢下来，可以试着用tbcheck工具检查索引的完整性，必要时进行修复。
