mysql索引

什么是索引？为什么要建立索引？索引分类？索引的使用？ 转载SQL(五) MySQL中的索引详讲 一、索引介绍： 　　索引用于快速找出在某个列中有一特定值的行。不使用索引，MySQL必须从第一条记录开始读完整个表，直到找出相关的行，表越大查询数据所花费的时间就越多。如果表中查询的列有索引，MySQL能够快速到达一个位置去搜索数据文件，而不必查看所有数据，那么将会节省很大一部分时间。 　　例如：有一张person表，其中有2W条记录，记录着2W个人的信息。有一个Phone的字段记录每个人的电话号码，现在想要查询出电话号码为xxxx的人的信息。 　　如果没有索引，那么将从表中第一条记录一条条往下遍历，直到找到该条信息为止。 　　如果有了索引，那么会将 Phone 字段，通过一定的方法进行存储，好让查询该字段上的信息时，能够快速找到对应的数据，而不必在遍历2W条数据了。其中MySQL中的索引的存储类型有两种：BTREE、HASH。 也就是用树或者Hash值来存储该字段，更详细的查找逻辑就需要会算法的知识了。我们现在只需要知道索引的作用，功能是什么就行。 二、索引优缺点： 优点： 　　1、所有的MySql列类型(字段类型)都可以被索引，也就是可以给任意字段设置索引。 　　2、大大加快数据的查询速度。 缺点： 　　1、创建索引和维护索引要耗费时间，并且随着数据量的增加所耗费的时间也会增加。 　

1. InnoDB存储引擎体系架构 innoDB的存储引擎主要体系结构如上图所示 首先是工作线程：默认7个后台线程，分别是4个io thread(insert buffer、log、read、write),1个master thread(优先级最高),1个锁(lock)监控线程，1个错误监控线程。可以通过show engine innodb status来查看。新版本已对默认的read thread和write thread分别增大到4个，可通过show variables like 'innodb_io_thread%'查看。 每个线程操作的同一个块大内存池：该内存池中会被分为多个区域，分别是缓冲池(buffer pool)、重做日志缓冲池(redo log buffer)以及额外的内存池(additional memory pool)。内存池所负责也就是维护线程需要访问的数据结构、缓存磁盘文件的数据，方便快速读取，同时在对磁盘文件的数据修改之前在这里缓存，以及重做日志缓存等。具体配置可由 show variables like 'innodb_buffer_pool_size' 、 show variables like 'innodb_log_buffer_size' 、 show variables like 'innodb_additional_mem_pool_size

近期有一个业务需求，多台机器需要同时从Mysql一个表里查询数据并做后续业务逻辑，为了防止多台机器同时拿到一样的数据，每台机器需要在获取时锁住获取数据的数据段，保证多台机器不拿到相同的数据。 我们Mysql的存储引擎是innodb，支持行锁。解决同时拿数据的方法有很多，为了更加简单，不增加其他表和服务的情况下，我们考虑采用select... for update的方式，这样X锁锁住查询的数据段，表里其他数据没有锁，其他业务逻辑还是可以操作。 这样一台服务器比如select .. for update limit 0,30时，其他服务器执行同样sql语句会自动等待释放锁，等待前一台服务器锁释放后，该台服务器就能查询下一个30条数据。如果要求更智能，oracle支持for update skip locked跳过锁区域，这样能不等待马上查询没有被锁住的下一个30条记录。 下面说下mysql for update导致的死锁。 经过分析，mysql的innodb存储引擎实务锁虽然是锁行，但它内部是锁索引的，根据where条件和select的值是否只有主键或非主键索引来判断怎么锁，比如只有主键，则锁主键索引，如果只有非主键，则锁非主键索引，如果主键非主键都有，则内部会按照顺序锁。但同样的select .. for update语句怎么就死锁了呢？同样的sql语句查询条件和结果顺序都一致

文章目录 概念 有什么用？ 分类 物理存储顺序 逻辑存储 数据类型 b+ tree 索引列 存储引擎支持 Innodb Myisam 使用技巧 建索引 用索引 优化分析 常见面试题 参考文章 概念 mysql index官方文档 索引是数据库管理系统中一种数据结构，用以协助快速查询数据库表中数据，典型的索引结构如B+ tree。 有什么用？ MySQL索引的建立对于MySQL的高效运行是很重要的，索引可以大大提高MySQL的检索速度。 打个比方，如果合理的设计且使用索引的MySQL是一辆兰博基尼的话，那么没有设计和使用索引的MySQL就是一个人力三轮车。 拿汉语字典的目录页（索引）打比方，我们可以按拼音、笔画、偏旁部首等排序的目录（索引）快速查找到需要的字。 分类 物理存储顺序 MySQL的 Innodb 存储引擎的索引分为聚集索引和非聚集索引(二级索引)。 聚集索引是Innodb引擎才有的概念。 为什么说是按照物理存储顺序分类呢？因为聚集索引的逻辑顺序就是数据记录的物理顺序，而非聚集索引却不是如此。 举个例子，聚集索引就像是汉语字典中的拼音索引，字典中的字就是按照这个顺序存的。非聚集索引就像是部首索引，相同偏旁的字在索引页上是相邻的，但是真实的位置却不一定是相邻的。类似的例子还有电话簿，大家自行想象一下。 聚集索引怎么选定呢？ 第一个唯一且不能为NULL的列就会被选为聚集索引

数据库： 　　简而言之可视为 电子化 的 文件柜 --- 储存电子文件的处所，用户可以对数据进行 CURD 所谓数据库是以一点方式储存在一起，能与多个用户共享，与应用程序彼此独立的集合 数据库管理系统： 　　英文名 Database Management System （ DBMS ） 是为管理数据而设计的电脑管理软件 一般都有 存储 截取 安全保障 等基础功能 类型： 　关系型数据库 　　MySQL 　　Microsoft SQL Server 　　Microsoft Access 　　Oracle 　　PostgreSQL 　非关系型数据库（ NoSQL ） 　　详细介绍见另文↓（传送门） 　　https://www.cnblogs.com/lky-19990802/p/10596229.html 数据库索引 ： 　　主条目：数据库索引 　　数据索引的观念由来已久，像是一本书前面几页都有目录，目录也算是索引的一种，只是它的分类较广，例如车牌、身份证字号、条码等，都是一个索引的号码，当我们看到号码时，可以从号码中看出其中的端倪，若是要找的人、车或物品，也只要提供相关的号码，即可迅速查到正确的人事物。 　　另外，索引跟字段有着相应的关系，索引即是由字段而来，其中字段有所谓的关键字段（ Key Field ），该字段具有唯一性，即其值不可重复，且不可为 " 空值 （ null ） "

背景 在test数据库中，查询一组数据会根据id进行排序，而同样的条件在pre数据库中查询却没有根据默认的id主键来排序，于是激起了好奇心。 情况 正常情况下，在默认没有写order by条件的情况下，查询出来的结果会根据id主键从小到大的排序，例如在测试环境中会有： 但是在pre数据库中，则有： 分析 到底是什么原因导致了没有根据id来排序呢？第一点想到的一定是与表结构定义有关，左侧是test的表定义，右侧是pre的表定义 可以看到，两个表的只有索引不一样，在test数据库下，走的是INDEX_PLAN_ID的索引，而在pre数据库下，走的是联合索引idx_teach_plan_question，可能排序就与索引有关 验证 test数据库sql解释 pre数据库sql解释 发现查询条件走的索引和分析的一致。 另外当我们删除掉test数据库中该表的INDEX_PLAN_ID索引后，也会出现id乱序的情况，从另一个方面也验证了根据联合索引的排序。 结论 若查询条件中没有走索引，或者是走的普通索引，结果都会按照id主键从小到大排序 若查询条件走联合索引，则结果会按照联合索引的从左到右的字段先后顺序排序。 来源： CSDN 作者： zhuxingKevin 链接： https://blog.csdn.net/zhuxingKevin/article/details/103770977

所有文章 https://www.cnblogs.com/lay2017/p/12078232.html 正文 在上一篇文章中，我们简单了解了一下innodb的 行级锁（s锁、x锁） 和 表级锁（is锁、ix锁） 的概念以及锁之间的兼容关系。 本文，将了解一下innodb的几种加锁的情况： 常见的加锁 1）对于 update、delete、insert 这种涉及到commit操作的语句，innodb自动会给相关的数据集加上 排它锁 （X锁）。 2）对于 普通的select语句 ，innodb 默认是不会加锁 的。但是，一个 事务中 我们可以 显示地 给select语句 加上共享锁（S锁）或者排它锁（X锁） 。这里注意，必须开启事务，在begin和commit/rollback之间才生效。 　　2-1）共享锁（S锁），例如：　　 select * from t_table where...lock in share mode 　　其它事务仍然可以查询记录，或者也加上share mode地共享锁，但不可以加互斥锁。同时要注意，如果当前事务加了共享锁，又准备对该数据进行更新操作（加排它锁），那么 可能就造成了死锁 。 　　2-2）排它锁（X锁），例如： select * from t_table where...for update 　　其它事务可以查询该记录

一、优化分类 二、测试数据样例 参考mysql官方的sakina数据库。 三、使用mysql慢查询日志对有效率问题的sql进行监控 第一个，开启慢查询日志。第二个，慢查询日志存储位置。第三个，没有使用索引的也会记录到慢查询日志中。第四个，超过1秒之后的查询记录到慢查询日志中（通常设置100ms）。 3.1、分析慢查询日志文件 3.1.1 tail命令 tail -50 /home/mysql/sql_log/mysql_slow.log，输入文件中的尾部内容，即末尾50行数据. 我们抽出其中一条，查看，如下图所示。 query_time,查询耗时(单位秒)；lock_time，锁表时间。rows_sent,发送请求的行数；rows_examined，查询数据导致扫描表用到的行数。 3.1.2 官方mysqldumpslow工具 mysqldumpslow ，默认随mysql安装。 mysqldumpslow -h，可查询工具支持的命令。 mysqldumpslow -s r -t 10 /var/lib/mysql/localhost-slow.log | more ，返回结果如下图所示。 3.1.3 pt-query-digest工具 比mysqldumpslow反馈的信息多。 pg-query-digest --help 查看帮助，查看使用命令。 pg-query-digest

一个Next-key锁结合了行锁和gap锁。 InnoDB执行一个行级别锁在这样的一个途径，那就是它搜索或者扫描一个表索引时，它设置共享或者独占锁在它遭遇的索引记录上。于是，行级锁是真实的行记录锁。一个next-key锁在一个行记录上总是这个行记录前的间隙。这就是一个next-key是一个索引记录锁加上一个在这个记录前的间隙锁。如果一个会话有一个共享锁或者一个独占锁在一个索引的记录R上，另外的会话不能插入一个新索引记录在R前的间隙。 猜测一个索引包含10，11，13，20。可能这个索引的next-key锁盖以下间隔，这个间隔在一个圆括号表示的排除节点符号和一个方括号表示包含节点符号。 看这个最后的间隔，next-key锁锁定在索引中上面的最大值和一个“临界值”伪记录，这个伪记录有一个比任何实际值都高的值，这个伪记录不是真实的记录，因此，在这个影响下，这个next-key锁仅仅锁了跟随在最大索引值的间隙。 默认情况下，InnoDB操作在可重复度事务隔离级别，在这个案例，InnoDB使用next-key为查找和索引扫描锁定，防止phantom（幻影）行的出现。 事务数据为一个next-key锁展现到跟随在下面语句的输出： 来源： https://www.cnblogs.com/ck0074451665/p/10266142.html

MySQL数据库优化 概览 软优化 1.优化查询语句 2.优化子查询 3.命中索引 4.分解表 5.增加中间表 6.增加冗余字段 7.分析表、检查表、优化表 硬优化 1.cpu、内存、磁盘 2.配置参数 3.分库分表 4.缓存集群 概览 软优化 ：1.优化查询语句；2.优化子查询；3.命中索引；4.分解表；5.增加中间表；6.增加冗余字段；7.分析表、检查表、优化表 硬优化 ：1.cpu、内存、磁盘；2.配置参数；3.分库分表+读写分离；4.缓存集群 软优化 1.优化查询语句 使用EXPLAIN或者DESCRIBE（可简写为DESC）命令分析一条查询语句的执行信息 输入： DESC SELECT * FROM user 显示： select_type：代表查询类型，分为简单查询、子查询等等 type：代表查询策略，分为全表扫描（ALL）、索引合并（index_merge）等等 possible_keys：可能用到的索引 key：实际用到的索引 Extra：额外信息，包含Using intersect（index1，index2）、Using where、Using index等等 2.优化子查询 应该尽量使用join查询代替子查询。子查询是一个嵌套的查询，外层查询嵌套内层查询，查询时会建立内层查询的临时表，查询完毕会删除该临时表，建立和删除会有较大的系统开销