mysql索引

1 MyISAM和InnoDB的区别 　　 a 是否支持行级锁 : 　　MyISAM 只有表级锁 (table-level locking)， 　　而 InnoDB 支持行级锁 (row-level locking)和表级锁,默认为行级锁。 　　 b 是否支持事务和崩溃后的安全恢复： 　　 MyISAM 强调的是性能 ，每次查询具有原子性,其执行速度比InnoDB类型更快，但是不提供事务支持。 　　但是 InnoDB 提供事务支持事务 ，外部键等高级数据库功能。 具有事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表。 　　 c 是否支持外键： 　　MyISAM不支持，而InnoDB支持。 　　 d 是否支持MVCC ： 　　仅 InnoDB 支持。应对高并发事务, MVCC比单纯的加锁更高效;MVCC只在 READ COMMITTED 和 REPEATABLE READ 两个隔离级别下工作;MVCC可以使用 乐观(optimistic)锁 和 悲观(pessimistic)锁来实现;各数据库中MVCC实现并不统一。 2 索引 　　MySQL索引使用的数据结构主要有 BTree索引 和 哈希索 引 。 　　对于 哈希索引 来说

mysql数据库，卡系统运行了一段时间，后来卡号要求不可以重复，于是加了一个唯一索引 alter table card add unique(cardnum)，结果报错：ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes，我设置的cardnum长度是varchar(256)，于是修改该长度，改为varchar(64)，alter table card modify column cardnum varchar(64)，然后再执行增加唯一索引的语句，问题解决；网上说有要调整mysql的参数的方案，但是用不到，所以没有去使用那种办法。 来源： CSDN 作者： 威武 白 链接： https://blog.csdn.net/JamesBaiLove/article/details/104445126

转载 MySQL在 5.0版本中引入新特性：索引合并优化(Index merge optimization)，当查询中单张表可以使用多个索引时，同时扫描多个索引并将扫描结果进行合并。 该特新主要应用于以下三种场景： 1、 对OR语句求并集，如查询SELECT * FROM TB1 WHERE c1="xxx" OR c2=""xxx"时，如果c1和c2列上分别有索引，可以按照c1和c2条件进行查询，再将查询结果合并（union）操作，得到最终结果 2、 对AND语句求交集，如查询SELECT * FROM TB1 WHERE c1="xxx" AND c2=""xxx"时，如果c1和c2列上分别有索引，可以按照c1和c2条件进行查询，再将查询结果取交集（intersect）操作，得到最终结果 3、 对AND和OR组合语句求结果 该新特性可以在一些场景中大幅度提升查询性能，但受限于MySQL糟糕的统计信息，也导致很多场景查询性能极差甚至导致数据库崩溃。 以SELECT * FROM TB1 WHERE c1="xxx" AND c2=""xxx" 为例： 1、 当c1列和c2列选择性较高时，按照c1和c2条件进行查询性能较高且返回数据集较小，再对两个数据量较小的数据集求交集的操作成本也较低，最终整个语句查询高效； 2、 当c1列或c2列选择性较差且统计信息不准时

看了很多讲B树和B+树的文章，大多都是围绕各自的特性讲的，第一，树中每个结点最多含有m个孩子（m>=2）；第二，……我也是从这些文章里弄懂了各种树的联系与区别，要真写，我可能还不如人家写得好。所以就在这里简明扼要的用几张图记录一下主要区别吧。 为了便于说明，我们先定义一条数据记录为一个二元组[key,data]，key为记录的键值，key唯一；data为数据记录除key外的数据。 B树 每个节点都存储key和data，所有节点组成这棵树，并且叶子节点指针为null。 B+树 只有叶子节点存储data，叶子节点包含了这棵树的所有键值，叶子节点不存储指针。 后来，在B+树上增加了顺序访问指针，也就是每个叶子节点增加一个指向相邻叶子节点的指针，这样一棵树成了数据库系统实现索引的首选数据结构。 原因有很多，最主要的是这棵树矮胖，呵呵。一般来说，索引很大，往往以索引文件的形式存储的磁盘上，索引查找时产生磁盘I/O消耗，相对于内存存取，I/O存取的消耗要高几个数量级，所以评价一个数据结构作为索引的优劣最重要的指标就是在查找过程中磁盘I/O操作次数的时间复杂度。树高度越小，I/O次数越少。 那为什么是B+树而不是B树呢，因为它内节点不存储data，这样一个节点就可以存储更多的key。 在MySQL中，最常用的两个存储引擎是MyISAM和InnoDB，它们对索引的实现方式是不同的。 MyISAM

背景介绍 最近在写SQL语句时，对选择IN 还是Exists 犹豫不决，于是把两种方法的SQL都写出来对比一下执行效率，发现IN的查询效率比Exists高了很多，于是想当然的认为IN的效率比Exists好，但本着寻根究底的原则，我想知道这个结论是否适用所有场景，以及为什么会出现这个结果。 网上查了一下相关资料，大体可以归纳为：外部表小，内部表大时，适用Exists；外部表大，内部表小时，适用IN。那我就困惑了，因为我的SQL语句里面，外表只有1W级别的数据，内表有30W级别的数据，按网上的说法应该是Exists的效率会比IN高的，但我的结果刚好相反！！ “没有调查就没有发言权”！于是我开始研究IN 和Exists的实际执行过程，从实践的角度出发，在根本上去寻找原因，于是有了这篇博文分享。 实验数据 我的实验数据包括两张表：t_author表 和 t_poetry表。 对应表的数据量： t_author表，13355条记录； t_poetry表，289917条记录。 对应的表结构如下： CREATE TABLE t_poetry ( id bigint(20) NOT NULL AUTO_INCREMENT, poetry_id bigint(20) NOT NULL COMMENT '诗词id', poetry_name varchar(200) NOT NULL COMMENT

1.PRIMARY KEY（主键索引） mysql>ALTER TABLE `table_name` ADD PRIMARY KEY ( `column` ) 2.UNIQUE(唯一索引) mysql>ALTER TABLE `table_name` ADD UNIQUE (`column` ) 3.INDEX(普通索引) mysql>ALTER TABLE `table_name` ADD INDEX index_name ( `column` ) 4.FULLTEXT(全文索引) mysql>ALTER TABLE `table_name` ADD FULLTEXT ( `column` ) 5.多列索引 mysql>ALTER TABLE `table_name` ADD INDEX index_name ( `column1`, `column2`, `column3` ) 来源： https://www.cnblogs.com/roy-blog/p/9365647.html

什么是索引？索引就是排好序的数据结构，可以帮助我们快速的查找到数据 推荐一个网站，可以演示各种数据结构：https://www.cs.usfca.edu/~galles/visualization/Algorithms.html --------------------------------------------------------------- 图解几种数据结构： 二叉树：如果数据是单边增长的情况 那么出现的就是和链表一样的数据结构了，树高度大 红黑树：在二叉树的基础上多了树平衡，也叫二叉平衡树，不像二叉树那样极端的情况会往一个方向发展。 同样我们查找6，在二叉树中我们需要经过6个节点才能找到（1-2-3-4-5-6）,红黑树中我们只需要3个节点（2-4-6），但是mysql索引的数据结构并不是红黑树，因为如果数据量大了之后，树的高度就会很大。 B树：在红黑树的基础上，每个节点可以存放多个数据 这个时候我们查找6 只需要2个节点就可以了，而且树的高度也比红黑树矮。 B+树：B树的变种 你会发现非叶子节点是会重复的，就像上面4，在叶子节点上面也出现了4，这是为什么呢？因为它需要在叶子上面存放数据。那又是怎么存放数据的呢？ --------------------------------------------------------------- mysql索引为什么用B

mysql大数据量使用limit分页，随着页码的增大，查询效率越低下。 测试实验 1. 直接用limit start, count分页语句， 也是我程序中用的方法： select * from product limit start, count 当起始页较小时，查询没有性能问题，我们分别看下从10， 100， 1000， 10000开始分页的执行时间（每页取20条）， 如下： select * from product limit 10, 20 0.016秒 select * from product limit 100, 20 0.016秒 select * from product limit 1000, 20 0.047秒 select * from product limit 10000, 20 0.094秒 我们已经看出随着起始记录的增加，时间也随着增大， 这说明分页语句limit跟起始页码是有很大关系的，那么我们把起始记录改为40w看下（也就是记录的一般左右） select * from product limit 400000, 20 3.229秒 再看我们取最后一页记录的时间 select * from product limit 866613, 20 37.44秒 难怪搜索引擎抓取我们页面的时候经常会报超时，像这种分页最大的页码页显然这种时 间是无法忍受的。

用来记笔记的软件电脑端登不进去了，本来打算过了这段时期，专门总结下知识点，那就直接写在这里吧，有什么问题欢迎指出。 按功能分类 普通索引 唯一索引 主键索引 组合索引 外键索引 全文索引 按结构分类 B+ Tree索引：InnoDB和MyISAM Hash索引：Memory B+ Tree B+ Tree 是基于 B Tree 和叶子节点顺序访问指针进行实现的，一个节点中的key从左到右非递减排列。 Hash 哈希索引能以 O(1) 时间进行查找，但是失去了有序性： 无法用于排序与分组； 只支持精确查找，无法用于部分查找和范围查找。 InnoDB 存储引擎有一个特殊的功能叫“自适应哈希索引”，当某个索引值被使用的非常频繁时，会在 B+Tree 索引之上再创建一个哈希索引，这样就可以实现快速的哈希查找。 InnoDB存储引擎 InnoDB的数据文件本身就是索引文件。 叶子节点data域保存了完整的数据记录，这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引（这样的索引成为聚集索引）。 InnoDB的辅助索引data域存储相应记录主键的值。这使得按主键的搜索十分高效，但是辅助索引搜索需要检索两遍索引。 MyISAM存储引擎 MyISAM引擎使用B+Tree作为索引结构，叶节点的data域存放的是数据记录的地址，索引文件和数据文件是分离的。 比较

MySql（五）SQL优化-优化SQL语句的一般步骤 一、优化SQL语句的一般步骤 1.1 通过show status命令了解各种SQL的执行频率 1.2 定位执行效率较低的SQL语句 1.3 通过explain分析低效sql的执行计划 1.4 通过show profile分析sql 1.5 通过trace分析优化器如何选择执行计划 1.6 确定问题并采取相应的优化措施 一、优化SQL语句的一般步骤 1.1 通过show status命令了解各种SQL的执行频率 Mysql客户端连接成功后，通过 show [ session | global ] status 命令可以提供服务器状态信息。 show [session|global] status 可以根据需要加上参数"session"或者"global"来显示seesion级（当前连接）的统计结果和global级（自数据库上次启动至今）的统计结果。如果不写，默认使用的参数时"session"。 例如：显示当前session中所有统计参数的值： mysql > show status like 'Com_%' ; Com_xxx表示每个xxx语句执行的次数。 Com_select：执行select操作的次数，一次查询之累加1. Com_insert：执行insert操作的次数，对于批量插入insert操作，只累加一次。 Com