索引完美版教案.docxVIP

笔记 TIME \@ yyyy/M/d 2015/4/15 PAGE6 / NUMPAGES23 索引 前缀索引 建立索引关键字一种方案。 通常会使用字段的整体作为索引关键字。 有时，即使使用字段前部分数据，也可以去识别某些记录。 语法： Index `index_name` (`index_field`(N)) 使用index_name前N个字符建立的索引。 N，究竟是多少？ 使用N长度所达到的辨识度，极限接近于使用全部长度的辨识度即可！ 计算最大的辨识度： 依次取得前N个字符，进行对比，找到极限接近的： 可见，9 时，已经极限接近，提高长度，不能明显 提升辨识度，因此可以使用前9个字符： Tip：前缀索引不能用于索引覆盖！ 全文索引 该类型的索引特殊在：关键字的创建上。 为了解决 like ‘%keyword%’这类查询的匹配问题。 测试： 业务： 查询 标题或者内容包含 database 关键字的记录。 形成的SQL如下： Select * from articles where title like ‘%database%’ or body like ‘%database%’; 此时不能建立普通索引，查询不符合 左原则，建立了也使用不了。 此时 全文索引就可以其作用了： 直接使用上面的SQL： 需要使用特殊的全文索引匹配语法才可以生效： Match() against(); Tip: 该MYSQL提供的全文索引，不能对中文起作用！ Match() against() ,返回的关键字的匹配度（关键字与记录的关联程度）。 停止词： 发现in这个词，是不能被全文索引所检索到的。 思考：与 like %in% 是否相同？b 不同。 原因何在呢？ 全文索引索引的的关键字，不是整个字段数据，而是从数据中提取的关键词。 索引的数据结构-了解 Hash B-Tree（B树） 两种数据结构。指的是mysql存储索引所采用的数据结构。其中，用户所维护的所有的索引结构 B-Tree结构 B-Tree的结构如下： 每个节点，存储多个关键字。 关键字也会对应记录地址 以上设计为了解决，一次性磁盘IO开销，可以读取到更多的关键字数量。 每个关键字之间，存在子节点指针 如果是复合索引： 关键字的排序先排左侧字段，在左侧字段相同的情况下，再排序右侧字段： 聚集索引，聚簇索引 B+Tree(B-Tree的变种) 在innodb的存储引擎上，主索引是与数据记录 存储在一起的（聚簇在一起的）。 带来的问题： Innodb的其他索引，非主键索引（二级索引）： 关键字对应的不再是记录的地址，而是记录的主键。 可见，检索需要 二次检索。先检索到主键ID，在检索记录。 查询缓存 query_cache 将select的结果，存取起来共二次使用的缓存区域： MySQL提供的缓存区： 未开启前： 两次查询时间消耗一致。 开启查询缓存： 通过变量控制： 开启并设置大小： 再次执行查询： 可见，第二次查询，使用了开启的缓存！ 注意事项： 查询缓存存在判断是严格依赖于select语句本身的：严格保证SQL一致 如果查询时包含动态数据，则不能被缓存。 一旦开启查询缓存，MySQL会将所有可以被缓存的select语句都缓存。如果存在不想使用缓存的SQL执行，则可以使用 SQL_NO_CACHE语法提示达到目的： 分表 分区，partition 分表，水平分表，分裂 将某张表数据，分别存储到不同的区域中。 其实：每个分区，就是独立的表。都要存储该分区数据的数据，索引等信息。 创建分区： 在创建表时，指定分区的选项： Create table table_name ( 定义 ) Partition by 分区算法 (参数) 分区选项。 Tip：分区与存储引擎无关，是MySQL逻辑层完成的。 通过变量查看当前mysql是否支持分区： 分区算法： MySQL提供4种 取余：Key，hash 条件：List，range 提示，参与分区的参数字段需要为主键的一部分。 KEY – 取余 按照某个字段进行取余 Hash – 取余 按照某个表达式的值进行取余 学生表分区，按照生日的月份，划分到12个表中。 Tip： Key，hash都是取余算法，要求分区参数，返回的数据必须为整数。 List – 条件 – 列表 需要指定的每个分区数据的存储条件。 按照生日中的月份，分成春夏秋冬四个分区。 List，条件依赖的数据时列表形式。 Range - 条件 – 范围 Range：条件依赖的数据是一个条件表达式。 逻辑：按照生日的年份分成 管理分区语法 取余：key，hash 增加分区数量： Add partition N 减少分区数量： COALESCE partition