高性能Mysql读后感(三)-其他一些关于索引的话

其他一些关于索引的话

建立索引

** 所建立的索引最好支持多种过滤条件 **

** 在所建立的索引列上避免多个范围条件 **

** 过滤数据的同时最好能照顾到排序 **

维护索引和表

找到并修复损坏的表 ( corruption )

分为 ** 索引损坏 ** 和 ** 数据损坏 **

check table 来检查是否发生了表损坏 (MyISAM友好)
repair table 修复损坏的表 (MyISAM友好)
InnoDB 表 alter table t1 ENGINE=INNODB; 来重建表.
如果数据损坏了, 恢复备份吧.

维护索引统计信息

mysql 的查询优化器会通过两个API接口 records_in_range() 和 info() 提供的索引值分布信息, 来决定
如何使用索引.

records_in_range(): 通过向存储引擎传入两个边界值 来获取 这个范围大概有多少条记录.
MyISAM 返回精确值: InnoDB 返回估算值.
info(): 返回各种类型的数据, 索引的基数(每个索引有多少条记录)等等.

** mysql 优化器使用基于成本的模型, 衡量成本的主要指标就是一个查询需要扫描多少行. 所以, 如果 mysql 优化器 records_in_range() 和 info() 提供的信息不准确. 那么优化器可能做出错误的决定.**

ANALYZE TABLE —> 重新生成统计信息

  • Memory 引擎不存储统计信息
  • MyISAM 将统计信息 存储在 磁盘中, ANALYZE TABLE 需要进行一次全索引扫描来计算索引基数. (整个过程会锁表)
  • mysql5.5 及其以前的版本, InnoDB 不保存索引统计信息在磁盘, 而是通过随机的索引访问进行评估并保存在内存中.
    ps: InnoDB 在首次打开表, 或是 执行 ANALYZE TABLE , 或是 表的大小发生了非常大的变化(大小变化超过了1/16或插入了20亿行数据) 的时候计算索引的统计信息. ** 在表的数据量很大时, 这可能会产生严重的性能问题, I/O 和 锁 **
减少碎片

** 索引的碎片 ** 和 ** 数据的碎片 **

** 索引的碎片化 ** 会降低查询效率, 尤其是 范围查询, 索引覆盖扫描等.

** 数据的碎片 **

  • 行碎片: 单条数据行 被存储在多个地方的多个片段中. (根据 id 去访问一条数据行, 也会产生影响)
  • 行间碎片: 多个数据行之前 不是被顺序的存储在磁盘中. (对全表扫描和聚簇索引扫描有很大影响影响)
  • 剩余空间碎片: 硬盘上的 ‘数据页’ 中有大量的空余空间. (服务器会读取大量不需要的数据, 浪费)

MyISAM 三种情况都会发生, InnoDB 不会出现短小的行碎片, 会将其合并到一个片段中.
** OPTIMIZE TABLE ** 来优化表 , 不支持此命令的 存储引擎可以 alter table t1 ENGINE=< engine >来操作.

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值