MySQL使用纪要

《MySQL索引知识汇总》

一、索引基础

1、索引的设计原则

1）对于经常作为查询条件、使用频率比较高的字段，可以设置为索引列；
2）建立索引，尽量使用全表唯一的字段，建立唯一索引，这样查询效率更高；
3）建立组合索引时，注意字段顺序；
4）索引并不是越多越好。
首先，过多的索引会降低DML（数据库操作语言）的执行速度；
其次，因为每次操作表都要维护索引，所以需要频繁增、删、改的表，sql执行会受很大影响。
对于数据量少、查询少的表尽量不要建立索引。

2、explain各字段说明

A、简介

explain是mysql查看某个语句执行情况的命令，只要在要分析的sql前加explain就可以看到结果。
也选中要分析的sql，然后使用navcat的解释按钮。

B、各字段说明

explain返回的结果包含多个字段，知道它们各自的含义，有助于分析sql的性能

1）id：查询序列号

MySQL 会为每个 select 语句分配一个唯一的 id 值，用来表示查询中执行 select 子句或者操作表的顺序。
如果只是单纯的查一个表，那么 id 就是 1。
如果查询的是多个表、且 id 值相同，则表示查询的优先级是相同的，那么执行顺序即为从上到下，常见于子查询。
如果 id 不同（子查询，id 的序号会递增），id 值越大表示优先级越高，越先被执行。
如果同时存在 id 相同和不同的，则相同的 id 可以认为是一组，从上往下顺序执行；在所有组中，id 值越大，优先级越高，越先执行。

2）select_type：查询类型。

主要用来区分查询类型是“普通查询”、还是“联合查询”、还是“子查询”。
常见的类型值有：
simple：简单的查询，不包含子查询和 union；
primary：查询中若包含复杂的子查询，最外层查询则被标记为 primary；
union：在 union、union all、子查询中的第二个以及第二个之后的select 会被标记为 union；
dependent union：在包含 union 或者 union all 的大查询中，如果各个小查询都依赖于外层查询的话，那除了最左边的那个小查询之外，其余的小查询的 select_type 就是 dependent union
union result：从 union 表获取结果的 select 会被标记为 union result
sebquery：在 select 或者 where 列表中包含子查询（不在from子句中）
dependent sebquery：子查询中的第一个 select（不在 from 子句中），并且取决于外层查询
derived：在 form 列表中包含的子查询被标记为 derived，也叫做派生类
uncacheable sebquery：一个子查询的结果不能被缓存
uncacheable union：表示 union 的查询结果不能被缓存
table：表示 explain 语句正在访问哪个表，表名或者别名，可能是临时表或者 union 合并结果集。如果是具体的表名，则表明从实际的物理表中获取数据，当然也可以是表的别名；表名是 derivedN 的形式，表示使用了 id 为 N 的查询所产生的衍生表；当有 union result 的时候，表名是union n1,n2 等的形式，n1,n2 表示参与 union 的 id.

3）type：访问类型

表示以何种方式去访问数据库，最容易想的是全表扫描，即直接暴力的遍历一张表去寻找需要的数据，效率非常低下。

访问的类型有很多，效率从最好到最坏依次是：system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

system：表只有一行记录（等于系统表），这是 const 类型的特例，平时不会出现，不需要进行磁盘 io
const：最多只能匹配到一条数据，通常使用主键或唯一索引进行等值条件查询
eq_ref：当进行等值联表查询使用主键索引或者唯一性非空索引进行数据查找时（实际上唯一索引等值查询 type 不是 eq_ref 而是 const）
ref：使用了非唯一性索引进行数据的查找
ref_or_null：对于某个字段既需要关联条件，也需要 null 值的情况下，查询优化器会选择这种访问方式
index_merge：在查询过程中需要多个索引组合使用
unique_subquery：该连接类型类似于 index_subquery，使用的是唯一索引。大多数情况下使用 SELECT 子查询时，MySQL 查询优化器会自动将子查询优化为联表查询，因此 type 不会显示为 index_subquery，而是 eq_ref
index_subquery：利用索引来关联子查询，不再扫描全表。但是大多数情况下使用 SELECT 子查询时，MySQL 查询优化器会自动将子查询优化为联表查询，因此 type 不会显示 index_subquery，而是 ref
range：表示利用索引查询的时候限制了范围，在指定范围内进行查询，这样避免了 index 的全索引扫描。适用的操作符：=, <>, >, >=, <, <=, is null, between,like, or, in
index：全索引扫描这个比 all 的效率要好，主要有两种情况，一种是当前的查询覆盖索引，即需要的数据在索引中就可以索取，或者是使用了索引进行排序，这样就避免了数据的重排序
all：全表扫描，需要扫描整张表，从头到尾找到需要的数据行。一般情况下出现这样的 sql 语句而且数据量比较大的话那么就需要进行优化
一般情况下，要保证查询至少达到 range 级别，最好能达到 ref

4）possible_keys：显示查询可能使用哪些索引来查找

即显示可能应用在这张表中的索引，一个或多个，查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询实际使用

5）key：这一列显示 mysql 实际采用哪个索引来优化对该表的访问

即实际使用的索引，如果为 null ，则表示没有使用索引

6）key_len：表示索引中使用的字节数

可以通过 key_len 计算查询中使用的索引长度，在不损失精度的情况下长度越短越好。索引越大占用存储空间越大，这样 io 的次数和量就会增加，影响执行效率

7）ref：显示之前的表在 key 列记录的索引中查找值所用的列或者常量

8）rows 列：根据表的统计信息及索引使用情况

大致估算出找出所需记录需要读取的数据行数，此参数很重要，直接反应 sql 找了多少数据，在完成目的的情况下越少越好

9）filtered：针对表中符合某个条件（where 子句或者连接条件）的记录数的百分比所做的一个估算

10）extra 列：显示不适合在其它列的额外信息

虽然叫额外，但是也有一些重要的信息：
using filtersort：说明 mysql 无法利用索引进行排序，只能利用排序算法进行排序，会消耗额外的位置
using index：表示当前的查询是覆盖索引的，直接从索引中读取数据，而不用访问数据表。
单独using index，即通过聚簇索引直接查到数据；
如果是using index + using where，表示索引被用来执行索引键值的查找；
using where：使用 where 进行条件过滤
using temporary ：建立临时表来保存中间结果，查询完成之后把临时表删除
using join buffer：使用连接缓存
impossible where：where 语句的结果总是 false

3、组合索引

1）建立组合索引，要注意顺序；主要是索引的第一个字段选择要慎重

组合索引的第一个字段，为了方便、可以叫做“引导列”。
只要查询条件包含引导列，无论使用几个组合索引字段、无论顺序如何，查询都会命中组合索引；反之，如果查询条件没有用到引导列，查询100%不会命中组合索引。所以为了提高查询效率，请把经常作为查询条件的字段放在第一位

2）只要包含引导列，查询就会命中组合索引，与顺序无关

3）组合索引列全在where中，就可以命中索引；跟顺序无关。

4）where条件只用到组合索引的非引导列，无法命中索引。

二、InnoDB的“聚簇索引”

1、InnoDB的主键索引（聚簇索引）

1）InnoDB的主键索引就是聚簇索引
2）聚簇索引并不是一种单独的索引类型，而是一种数据存储方式。
3）聚簇索引，就是主键位于树干、数据行存于叶子的一棵B+树；数据行本身也是索引的一部分
4）也就是说“inodb的表数据就是按B+Tree结构存放的”。

4）innodb中，一般建表会用一个自增主键做聚簇索引，没有的话MySQL会默认创建，但是这个主键如果更改代价较高，故建表时要考虑主键ID不能频繁update这点。
实际工作中，为了不频繁修改主键id（这会导致修改聚簇索引的结构）、根据实际情况自行添加的索引叫做辅助索引（辅助索引也可以叫“非聚簇索引”），辅助索引就是一个用于寻找主键的二级索引，找到主键之后，再通过主键索引找数据。

2、聚簇索引的优缺点

优点：
数据访问更快，因为聚簇索引将索引和数据保存在同一个B+树中，因此从聚簇索引中获取数据，无论是普通的等值查询，还是排序查找和范围查找速度都非常快，对比比非聚簇索引优势明显（尤其在表数据量大的时候）。
缺点：
a、插入速度严重依赖于插入顺序，按照主键的顺序插入是最快的方式，否则将会出现页分裂，严重影响性能。因此，对于InnoDB表，我们一般都会定义一个自增的ID列为主键。
b、更新主键的代价很高，因为将会导致被更新的行移动。因此，对于InnoDB表，我们一般定义主键为不可更新。
c、辅助索引访问需要两次索引查找，第一次找到主键值，第二次根据主键值找到行数据。

四、MyISAM的“非聚簇索引”

MyISAM（发音为：my-zeim），与InnoDB不同的时、其索引文件和数据文件是分离的，索引文件仅保存数据记录的地址

1、MyISAM的主键索引

MyISAM也使用B+Tree作为索引结构，但其叶节点存放的是数据记录的地址、而不是数据本身。
MyISAM中索引检索的算法首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，则取出其叶节点data域的值，然后以此值为地址，读取相应数据记录。
下图是MyISAM主键索引查询的原理图：

2、MyISAM的辅助索引

在MyISAM中，主键索引和辅助索引（Secondary key）在结构上没有任何区别，只是主键索引要求key是唯一的，而辅助索引的key可以重复。
辅助索引的结构如下图所示。
如果把辅助索引与主键索引对比，两棵B+树看上去没什么不同，节点的结构完全一致只是存储的内容不同而已，主键索引B+树的节点存储了主键，辅助键索引B+树存储了辅助键。表数据存储在独立的地方，这两颗B+树的叶子节点都使用一个地址指向真正的表数据，对于表数据来说，这两个键没有任何差别。
由于索引树是独立的，MyISAM通过辅助键检索无需访问主键的索引树。

3、非聚簇索引（非聚集索引）

MyISAM的索引方式叫做**“非聚集索引”**，之所以这么称呼是为了与InnoDB的聚集索引区分。

为了更形象说明这两种索引的区别，我们假想一个表如下图存储了4行数据。其中Id作为主索引，Name作为辅助索引。图示清晰的显示了聚簇索引和非聚簇索引的差别。

五、覆盖索引

覆盖索引就是要查询的字段，都包含于索引结构、不需要再回表查询、就可以得到结果的查询方式。
“覆盖索引”不是一种索引类型，而是一种查询方式（或许叫“索引覆盖”更合适一些）。
与“覆盖索引”对应的就是回表查询。

1）最常见的使用覆盖索引的情况，就是只查询作为索引的字段；
比如，id是主键索引，那么select id from table where id like 'xxx%'肯定是覆盖索引的查询方式；
再如，name，age建立了组合索引，那么select name,age from table where name="xxx" 也是覆盖索引查询；

2）另外，辅助索引字段虽然与主键没有建立组合索引，但是因为辅助索引底层数据结构，就是与主键索引相关联，所以它们即使没有建立组合索引、查询时也符合覆盖索引。

下面上一些实测截图。

测试表结构如下图，id为主键，并对user_id、credit_card_no建立辅助索引：

测试1，id与user_id并未建立组合索引，但辅助索引与主键索引关联，查询id、user_id时，符合覆盖索引，解释计划explain的extra字段值为“Using index”说明是覆盖索引

测试2，反过来以id为查询条件，查询id、user_id却不属于覆盖索引，我不理解、但测试结果是这样，有没有懂哥解释一下？还是说主键查询优于一切，就不过多说明了？

测试3，通过user_id查询id、user_id、credit_card_id也不符合覆盖索引，user_id、credit_card_id都建了索引，这说明不同于与主键索引，辅助索引之间底层数据结构是没有关联的

3）覆盖索引有什么用呢？
A、首先，因为这种查询方式，只查索引文件、不用回表，所以效率非常高，即使在表数据很大的情况下，通过覆盖索引查询速度也非常快；
B、其次，这种方式可以突破一些索引失效的桎梏：
比如，通常like查询，如果不符合最左前缀，像select * from table where name like '%三丰'或者select name, age from table where name like '%三丰'这种%在前的模糊查询，即使给name字段建立了索引、查询也不走索引。
但是如果对name、age建立组合索引，这时select name, age from table where name like '%三丰'符合覆盖索引，查询就会走索引。

3）那么问题来了：既然不用回表查询，就属于覆盖查询；而以innodb为引擎的表，会依主键建立聚簇索引、其行数据都在叶子节点上，那么通过主键查询全部、或者部分字段，应该就不需要回表查吧？这属于覆盖索引吗？

我想是符合的，但通过实测却发现，innodb表通过主键查询全部、或者部分字段都不是覆盖索引。

另外，innodb表通过主键模糊查询行数据，也无法突破%在前导致索引失效的桎梏。
测试表结构如下图

第一个，查询条件是对主键进行%在前的模糊查询，查询全部字段；结果不走索引
第二个，查询条件是对主键进行%在前的模糊查询，查询部分字段；结果不走索引

第三个，查询条件是对主键进行%在前的模糊查询，只查主键；结果走索引（看上去，主键索引也没有“特殊待遇”，和辅助索引一样…）

综上反推可知：
即使是通过聚簇索引，要查全部字段也不属于覆盖索引的查询方式；
只有查询字段，都属于索引字段的时候，才属于覆盖索引。
所以，如果想要、需要使用覆盖索引，就只能通过对要查的字段建立索引（这种方式只有模糊查询时才有意义）；如果要查多个字段，就只能对这多个字段建立组合索引。

六、索引失效

1、情况一：查询结果数据行过多（即mysql估计使用全表扫描要比使用索引快）

查询结果过多、即超过一定阈值就不走索引了，直接全表扫描。
这个阈值是查询结果与表总行数的比值，阈值并不固定，一般在20%~30%之间。
很多索引失效的情况，都不是绝对的；
很多索引失效的情况，底层都是相同的原因；
这是什么意思呢？我举几个例子

1）where查询条件，使用> 、>=、< 、<=、!= 、not in 、is null时会造成索引失效

我在网上看到过很多这样的说法，其实这种表述是不准确的；应该说这种情况“可能”会造成索引失效。
使用> 、>=、< 、<=、!= 、not in 、is null这些不等于条件，作的是范围限定，多数时候符合条件的数据有很多，所以非常容易造成“查询结果大于阈值”，我们已经知道查询结果过多是不走索引的；但并不是不等值查询都不走索引，关键还是要看它的查询结果有没有超过阈值。
来验证一下，测试表结构如下，对字段dict_sort建了辅助索引：

测试sql，作不等值查询，满足条件的数据只有一行、肯定没有超过阈值，所以不等值查询也会走索引

除了> 、>=、< 、<=、!= ，not in 、is null也一样，只不过，使用is null，is not null、not in这些，很少有查询结果不超过阈值的。
但底层原因咱要清楚，不是说规定了，用了> 、>=、< 、<=、!= ，not in 、is null这些就一定不走索引，只是因为用了它们大概率查询结果会过多，所以大概率不走索引。

2）where查询条件使用OR，不会命中索引；这种情况可以考虑改用 UNION

这种说法我也看到很多，也是不准确，使用or并不一定会导致索引失效，比如下图所示

同样的道理，会不会走索引，核心是查询结果是不是过多？当结果没有超过阈值时，还是会走索引的。
只是使用or，是找两个条件的交集，很多情况结果很多、会超过表总数据的30%，就很容易不走索引。

那“使用or的查询，可能会不走索引，建议改成union”这种说法有没有道理呢？
有道理，因为or两边的条件，是算作一次查询；而union两边的查询是算两次查询的。
假设有一个or查询，or前边的条件查询结果占表总数据的15%，or后边的条件查询结果占表总数据的16%，使用or是查它们的并集，假设没有重复，合并之后的结果占总数据的31%，超过阈值了，那么这个查询就不会走索引。
同样是上面说的两个条件，拆分成两个查询，用union连接，它是算作两次查询的；因为这两次查询一个结果占总数居15%、一个占16%，所以都没超阈值，都会走索引。

补充：使用关键字union 或 union all实现多条查询结果的拼接，两者区别是，union会自动去重；nion All不会去重。

3）where查询条件使用like，%在前不走索引，%在后走索引（违背最左匹配原则）

使用like，%在前不走索引，除非符合覆盖索引；
而使用like，%在后走不走索引？
不一定；还是要看查询结果是否超过阈值。

图中例子，使用like模糊查询，且%在后，但是表总共29条数据，本次查询结果是11条，超过了总数据的30%；所以本次查询并没有走索引。

2、情况二：字段上有运算

1）直接在列上运算

以下两条sql返回的结果一样，但列上有运算的不走索引

SELECT * from sys_dict_data WHERE dict_sort+1=100;   // 全表 

SELECT * from sys_dict_data WHERE dict_sort=100-1;  // 索引

2）列上使用函数

以下两条sql返回的结果一样，但列上使用函数的不走索引

select * from test where to_char(CREATED, 'yyyy-mm-dd hh24:mi:ss') = '2021-04-01 22:24:03';  // 全表

select * from test where CREATED = to_date('2021-04-01 22:24:03', 'yyyy-mm-dd hh24:mi:ss');  // 索引

3）隐式转换

当字符类型 和 数值类型作比较时，数据库会把字符类型转换成数值类型，即 TO_NUMBER(“STR_ID”)=3 ，然后比较。
假设表中有一字段STR_ID为字符串类型，那么会造成下述情况

a. select * from test where str_id = '3';   // 索引

b. select * from test where str_id = 3;     // 全表

b没命中索引，是因为数据库对字段做了隐式转换，即 TO_NUMBER(“STR_ID”)，这就相当于对字段使用函数了。

那么如果列是数字类型呢？以下两个sql都会走索引，这是因为’3’会变成3，没有发生列的隐式转换

a. select * from test where data_object_id = 3;  // 索引

b. select * from test where data_object_id = '3';  // 索引

【延申】：mysql建表，主键尽量使用数字类型，而不是字符类型

其实对于后端，主键是数字还是字符串，都无所谓；
关键是数据库，主键若为字符类型（char或者varchar），那些根据主键查询数据的sql，有时传的入参是数字类型，此时数据库就会对主键进行隐式转换，导致索引失效。
根据主键查询，本来是消耗最小的查询，上述情况发生、造成索引失效，会无故多耗费资源、降低效率。
所以，不如一开始就把主键设置为数字类型，前面说了，数字类型是不会出现隐式转换的。

3、情况三：计划使用组合索引，但没用引导列，不会命中索引

4、情况四：索引自身失效（比较少见，我还没遇到过）

每次修改表数据并且涉及到索引字段时，索引文件也需要同时做修改；索引有自我维护能力，但频繁修改表内容，可能会导致索引失效（就是改的太多了，自我修复失败），这时需要删除表、重建索引才能恢复。

《MySQL的常用sql》

一、时间字段处理

1、时间戳转换

数据库时间存的是时间戳、字段类型是bigint，即自1970年1月1日以来的秒数；这种情况查询时，经常需要转换成日期格式。
1）最简单的方式，是使用FROM_UNIXTIME()函数，例如

SELECT g.create_time 时间戳, FROM_UNIXTIME(g.create_time) 创建时间 
FROM es_goods g WHERE g.goods_belong=1;

其查询结果就是：

2、取时间的某级作为查询条件

可以通过函数：DATE(), MONTH(), YEAR()这些函数实现；eg：

# 查询table_a中当天数据行大于30的是那些天
SELECT * FROM table_a GROUP BY DATE(create_time) HAVING COUNT(*)>30

3、获取当前时间

可以用函数NOW()，例如

INSERT INTO es_disease_dict(id, name, type, create_time) 
VALUES (1, '21-羟化酶缺乏症', 1, NOW());

4、navicat通过excel导入失败(报错1900或1292)

导入设置，日期要根据excel具体的设置，作出对应配置；

然后，列不能为空；为空可能会报错1292。

二、自增主键

1、基础理解

1）字段设为 AUTO_INCREMENT 即自增时，数据库会单独找个地方存AUTO_INCREMENT自增值，其初始值默认为1；新插入数据行时，自增字段修改机制如下（假设id设为自增）：
a、如果插入语句没给id设值，则mysql会从AUTO_INCREMENT取当前自增值给id，然后AUTO_INCREMENT增长一个步长（步长默认为1）；
b、如果插入语句给id设值了，则mysql会以用户设的值执行插入语句，AUTO_INCREMENT如果比设的值大，则不作变化，如果比设的值小，则以步长为单位，逐步增长，直到大于设的值为止。
2）自增主键会遇到的问题

2、相关SQL

1）设置自增主键自增值

ALTER TABLE `es_disease_dict` AUTO_INCREMENT=1; 

注意，值要设置的比库中已有的值大，否则可能会因为重复报错

2）有时需要清空表、全部重新插入

TRUNCATE TABLE es_disease_dict;
ALTER TABLE `es_disease_dict` AUTO_INCREMENT=1; 

3）还有一种，不需要清除数据，但是把id全部重新改一遍、从1开始

alter table es_disease_dict drop column id;
alter table es_disease_dict add id bigint not null primary key auto_increment first;

《MySQL其他》

一、mysql数据库事务

1、mysql查看数据库事务提交方式

1）mysql数据库事务的提交方式有3种，分别为，自动提交，显式提交（也叫手动提交），隐式提交。

显式提交：用COMMIT命令直接完成的提交为显式提交。其格式为：SQL>COMMIT；

隐式提交：用SQL命令间接完成的提交为隐式提交。这些命令是：ALTER，AUDIT，COMMENT，CONNECT，CREATE，DISCONNECT，DROP，EXIT，GRANT，NOAUDIT，QUIT，REVOKE，RENAME。

自动提交：若把AUTOCOMMIT设置为ON，则在插入、修改、删除语句执行后，系统将自动进行提交。

mysql数据库默认提交方式是：自动提交

2）mysql查看事务提交方式

法一：

SHOW VARIABLES LIKE 'autocommit';

当value=ON时表示开启了自动提交

法二：

SELECT @@autocommit;

当@@autocommit=1时是自动提交，等于0是手动提交；

3）mysql修改事务提交方式

# 开启
SET AUTOCOMMIT ON;

# 关闭
SET AUTOCOMMIT OFF;

2、mysql数据库事务隔离级别

1）查看隔离级别

# 新版本(8.x)的系统
SELECT @@transaction_isolation;

# 旧版本(5.x)的系统
SELECT @@TX_ISOLATION;

2）修改隔离级别

// 语法
set session transaction isolation level xxx;

//eg:
//设置read uncommitted级别：
set session transaction isolation level read uncommitted;

//设置read committed级别：
set session transaction isolation level read committed;

//设置repeatable read级别：
set session transaction isolation level repeatable read;

//设置serializable级别：
set session transaction isolation level serializable;

二、mysql基本存储类型及范围

1、整型数据类型

1）TINYINT：占用1个字节，范围为-128~127。

2）SMALLINT：占用2个字节，范围为-32768~32767。

3）MEDIUMINT：占用3个字节，范围为-8388608~8388607。

4）INT：占用4个字节，范围为-2147483648~2147483647。

5）BIGINT：占用8个字节，范围为-9223372036854775808~9223372036854775807。

2、浮点型数据类型

1）FLOAT：占用4个字节，范围为-3.402823466E+38~3.402823466E+38，精度为单精度。

2）DOUBLE：占用8个字节，范围为-1.7976931348623157E+308~1.7976931348623157E+308，精度为双精度。

3、日期时间型数据类型

1）DATE：占用3个字节，存储年月日。

2）TIME：占用3个字节，存储时分秒。

3）DATETIME：占用8个字节，存储年月日时分秒。

4）TIMESTAMP：占用4个字节，存储年月日时分秒。

4、字符型、文本、二进制数据类型

A、字符类型

1）CHAR：固定长度，最多可存储255个字符。

2）VARCHAR：可变长度，最多可存储65535个字符。

B、文本类型

3）TINYTEXT：最多可存储255个字符。

4）TEXT：最多可存储65535个字符。

5）MEDIUMTEXT：最多可存储16777215个字符。

6）LONGTEXT：最多可存储4294967295个字符。

C、二进制文本类型

7）TINYBLOB：最大长度为255字节。
8）BLOB：最大长度为65,535字节。
9）MEDIUMBLOB：最大长度为16,777,215字节。
10）LONGBLOB：最大长度为4,294,967,295字节。

三种文本类型的取舍

1、VARCHAR有固定的最大长度，可以建立更有效率的索引，同时在查询时相对TEXT会更快一些，但VARCHAR需要设置最大长度，有时建表时并不能确定最大长度是多少，这时仍使用VARCHAR后面可能需要经常改表；
这种情况我一般会旋转TEXT，避免报错和改表。

2、TEXT可以存储非常大的文本内容，并且没有固定长度的限制，适合存储较长的文本数据，但是在查询和索引上可能会稍慢。

3、BLOB和TEXT类型在功能上很相似，但BLOB类型存储的是二进制数据。当你需要存储二进制格式的字符串时，BLOB类型会很有用。