mysql索引

一、innodb与myisam的区别与取舍、innodb引擎的4大特性 如下是两者的索引图： 两者的 相同点 ：两者都是mysql的常用引擎；两者的索引都是B+树 两者的 区别 ： 事务：InnoDB支持,MyISAM不支持 外键：InnoDB支持,MyISAM不支持 索引类型：InnoDB是聚簇索引(叶子节点存数据)，MyISAM是非聚簇索引(叶子节点存指针) 插入速度：MyISAM批量插入速度快 查询行数：MyISAM的查询性能会比InnoDB强，InnoDB查询表行数要全表扫描，MyISAM存在变量中直接读取 内存空间使用率：InnoDB比MyISAM高 全文索引：MyISAM支持。Innodb不支持,5.7以后才支持 压缩查询：MyISAM表格可以被压缩后进行查询操作 锁级别：InnoDB支持表级锁+(默认)行级锁，而MyISAM支持表级锁 主键：InnoDB必须有，MyISAM可没有 存储文件：Innodb存储文件有frm、ibd，而Myisam是frm、MYD、MYI PS1：InnoDB的 行锁是实现在索引上 的，而不是锁在物理行记录上。潜台词是，如果访问没有命中索引，也无法使用行锁，将要退化为表锁。 举个例子：t_user(uid, uname, age, sex) innodb; uid PrimaryKey，无其他索引 update t_user set age

IOS开发实训第十二周周报 总结： 在上一周，我基本实现了服务端的主要功能，本周的目标是进一步地优化服务器的性能，以便于它能更快的响应移动端的请求， 学习目标有： （1）数据库的优化策略 （2）服务器的优化策略 学习知识点归纳 1、数据库的优化策略 （1）数据类型的优化 更小的通常更好，因为它占用更小的磁盘、内存和cpu缓存，且处理时需要的cpu周期更小，但需要确保没有低估需要存储的值的范围； 简单的数据类型操作需要更少的cpu处理周期，如：整型比字符串代价更低、MySQL内建类型（date，time，datetime）而非字符串来存储时间、用整型存储IP地址； 尽量避免使用NULL，通常最好指定列为NOT NULL，除非真的需要存储NULL值，因为可为 NULL 的列使得索引、索引统计和值比较都更复杂，需要进行特殊处理； （2）索引优化 建立索引的优点：1、索引可以大大减少数据库表的扫描量；2、索引可以帮助服务器避免排序和临时表；3、索引可以将随机I/O变成顺序I/O； 索引类型： B-tree索引，所有数据按索引值顺序存储，并且每一个叶子叶到根的距离相等，适用于范围查找； 哈希索引：对于每一行数据，存储引擎都会对所有索引列计算一个哈希码，哈希索引将所有哈希码存储在索引中，同时在哈希表中保存指向每个数据行的指针，应用于某些频繁引用的索引值，他会在内存中基于B

一、SQL语句优化 （1）使用limit对查询结果的记录进行限定 （2）避免select *，将需要查找的字段列出来 （3）使用连接（join）来代替子查询 （4）拆分大的delete或insert语句 二、选择合适的数据类型 （1）使用可存下数据的最小的数据类型，整型 < date,time < char,varchar < blob （2）使用简单的数据类型，整型比字符处理开销更小，因为字符串的比较更复杂。如，int类型存储时间类型，bigint类型转ip函数 （3）使用合理的字段属性长度，固定长度的表会更快。使用enum、char而不是varchar （4）尽可能使用not null定义字段 （5）尽量少用text，非用不可最好分表 三、选择合适的索引列 （1）查询频繁的列，在where，group by，order by，on从句中出现的列 （2）where条件中<，<=，=，>，>=，between，in，以及like 字符串+通配符（%）出现的列 （3）长度小的列，索引字段越小越好，因为数据库的存储单位是页，一页中能存下的数据越多越好 （4）离散度大（不同的值多）的列，放在联合索引前面。查看离散度，通过统计不同的列值来实现，count越大，离散程度越高： mysql> SELECT COUNT(DISTINCT column_name) FROM table_name;

在日常工作中，我们有时会开慢查询去记录一些执行时间比较久的SQL语句，找出这些SQL语句并不意味着完事了，此时我们常常用到explain这个命令来查看一个这些SQL语句的执行计划，查看该SQL语句有没有使用上了索引，有没有做全表扫描。所以我们深入了解MySQL的基于开销的优化器，还可以获得很多可能被优化器考虑到的访问策略的细节，以及当运行SQL语句时哪种策略预计会被优化器采用。（QEP：sql生成一个执行计划query Execution plan） mysql> explain select * from servers; +----+-------------+---------+------+---------------+------+---------+------+------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+------+---------------+------+---------+------+------+-------+ | 1 | SIMPLE | servers | ALL | NULL | NULL | NULL | NULL |

回表：回到主键索引树搜索的过程，称为回表 覆盖索引：某索引已经覆盖了查询需求，称为覆盖索引，例如：select ID from T where k between 3 and 5 在引擎内部使用覆盖索引在索引K上其实读了三个记录，R3~R5(对应的索引k上的记录项)，但对于MySQL的Server层来说，它就是找引擎拿到了两条记录，因此MySQL认为扫描行数是2 最左前缀原则：B+Tree这种索引结构，可以利用索引的"最左前缀"来定位记录 只要满足最左前缀，就可以利用索引来加速检索。 最左前缀可以是联合索引的最左N个字段，也可以是字符串索引的最左M个字符 第一原则是：如果通过调整顺序，可以少维护一个索引，那么这个顺序往往就是需要优先考虑采用的。 索引下推：在MySQL5.6之前，只能从根据最左前缀查询到ID开始一个个回表。到主键索引上找出数据行，再对比字段值。 MySQL5.6引入的索引下推优化，可以在索引遍历过程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，减少回表次数。 来源： https://www.cnblogs.com/lakeslove/p/12238777.html

sql语句的实质行为就是从磁盘上的文件中读取数据，数据在磁盘上存储是随机IO，效率较低，所以我们需要“索引”B+tree 数据存储时是以页为单位存储的 为什么不用HashTable、二叉树？ HashTable的存储原理是：HashTable的底层也是数组，根据一定算法将key转化成下标，存储至数组中，查询是直接根据key算出下标从数据中拿到数据，K-V的结果不适合存储复杂数据结构的数据，比如一条数据中有多个字段需要存储，另外HashTable的存储顺序是随机的，不能查询大于、小于，只适合精确查找。 完全对称二叉树为什么不合适？ 因为二叉树存储是有序的，完全对称二叉树可以做大于、小于的运算，但是在查找过程中要回去查找父节点中储存的元素，不利于检索 B+tree B+tree也是有序的，在存储过程中是将所有非叶子节点的数据冗余一份到叶子节点中，在查找过程中只关注同级节点就可以了，所以B+tree的有点就在于区间查询，另外B+tree中一个节点存储了多个元素，有助于节省磁盘IO次数。 聚合索引：新建表是默认分配1页资源，索引与数据存在一起，插入数据达到本页最大限制时（默认16k），将第一页复制一份，并开辟一页新的资源，原第一页修改为目录页，以此类推，B+tree形成 ，建表时的第一页目录通常会被缓存，数据量越大，缓存越多。所以建表时务必指定主键索引，如果没有指定，也没有建其他唯一索引

什么是数据库调优？说得高大上，实际上就是减少磁盘IO次数。 众所周知，为数据表增加索引会使查询速度大大提升，MySQL索引其实是一种数据结构，有“哈希”和“B+树”可供用户选择。为什么只能用这两种呢？为什么不能用二叉树、平衡二叉树、红黑树等等呢？ 首先，来说一下MySQL增加数据的方式：一般都是主键自增的。根据二叉 树的特性：“左子树小于根节点，右子树大于根节点”，如果索引采用这种数据 结构，会生成一个向右倾斜的树，而且不会生成平衡二叉树。存放的数据越多， 树就越深，不能达到快速查询的目的。 如果采用红黑树，也一样只是生成一个比二叉树稍微改善一点的向右倾斜 的树而已。 上述两种数据结构并没有使磁盘IO次数减少。 我们知道“哈希”是一种散列算法，给定一个数据经过哈希运算后，能得到 一个固定长度的数列(哈希值)。MySQL索引存放哈希值，而哈希值所对应的是数 据的指针，因此哈希索引时间复杂度为O(1),查询速度极为迅速。 哈希索引有两个特点： 1.数据并不是按照索引值顺序存储，所以也就无法用于排序。 2.不支持任何范围查询 因为这两个缺陷，哈希索引只适用于某些特定的场合。 那B+树是怎么来解决上述的各种问题呢？ 不了解B+树是什么的同学可以点击链接 数据结构可视化 ，手动生成B+树并观察。 B+树允许每个结点拥有多个内部结点，“Max. Degree”代表每个结点的最大内部结点数量，B

这是你的表结构，有三个字段，分别是id,name,cid CREATE TABLE `student` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) DEFAULT NULL, `cid` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `name_cid_INX` (`name`,`cid`),) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8 索引方面：id是主键，(name,cid)是一个多列索引。 ----------------------------------------------------------------------------- 下面是你有疑问的两个查询： EXPLAIN SELECT * FROM student WHERE cid=1; EXPLAIN SELECT * FROM student WHERE cid=1 AND name='小红'; 你的疑问是：sql查询用到索引的条件是必须要遵守最左前缀原则，为什么上面两个查询还能用到索引？ --------------------------------------------------------------------

什么是Coreseek Sphinx默认不支持中文索引及检索，基于Sphinx开发了Coreseek全文检索服务器，Coreseek应该是现在用的最多的Sphinx中文全文检索，它提供了为Sphinx设计的中文分词包LibMMSeg包含mmseg中文分词。 安装 --解压安装包 # tar -zxvf coreseek-3.2.14.tar.gz # ls csft-3.2.14 mmseg-3.2.14 README.txt testpack 安装中文分词mmseg # cd mmseg-3.2.14/ # ./configure --prefix=/usr/local/mmseg --编译报错 config.status: error: cannot find input file: src/Makefile.in --运行下面指令再次编译就能通过了 # automake # make && make install --运行mmseg，输出安装信息则mmseg中文分词已经安装好了 # /usr/local/mmseg/bin/mmseg Coreseek COS(tm) MM Segment 1.0 Copyright By Coreseek.com All Right Reserved. Usage: /usr/local/mmseg/bin/mmseg <option>

目录 B-树 B+树 B+树相比B-树的优势 磁盘IO次数更少 查询性能更稳定 范围查询更简单 B-树 在B-树中，无论中间节点还是叶子节点都带有卫星数据（数据行记录） B+树 在B+树中，只有叶子节点带有卫星数据，中间节点仅仅是索引。 在MySQL中，主键索引的叶子节点直接包含数据行记录，二级索引叶子节点则包含主键键值，需要回表，即回主键索引中查找数据行记录 B+树相比B-树的优势 磁盘IO次数更少 B+树的每个节点都对应着一个磁盘页，树的高度意味着查询所经历的磁盘IO的次数。 由于B+树中间节点不包含数据记录，所以同样大小的磁盘页可以容纳更多的节点元素（关键字），B+树比B-树更加“矮胖”，磁盘IO次数更少。 查询性能更稳定 B+树的查询必须查到叶子节点，而B-树只要找到匹配元素即可，无论位于中间节点还是叶子节点，因此B-树查找性能不稳定（最好只查到根节点，最坏到叶子节点） 范围查询更简单 对于范围查询，比如要查3-11之间的元素 B-树的范围查找过程 自顶向下，查找到范围的下限（3） 中序遍历到元素6 中序遍历到元素8 中序遍历到元素9 中序遍历到元素11，遍历结束 B+树的范围查找过程 自顶向下，查找到范围的下限（3） 通过链表指针，遍历到元素6, 8 通过链表指针，遍历到元素9, 11，遍历结束 参考：https://blog.csdn.net/qq_35571554