Mysql版本>=5.5 默认的存储引擎，MySQL推荐使用的存储引擎。支持事务，行级锁定，外键约束。事务安全型存储引擎。更加注重数据的完整性和安全性。
存储格式 : 数据，索引集中存储，存储于同一个表空间文件中。
InnoDB的行锁模式及其加锁方法： InnoDB中有以下两种类型的行锁：共享锁（读锁： 允许事务对一条行数据进行读取）和 互斥锁（写锁： 允许事务对一条行数据进行删除或更新）， 对于update，insert，delete语句，InnoDB会自动给设计的数据集加互斥锁，对于普通的select语句，InnoDB不会加任何锁。
InnoDB行锁的实现方式： InnoDB行锁是通过给索引上的索引项加锁来实现的，如果没有索引，InnoDB将通过隐藏的聚簇索引来对记录加锁。InnoDB这种行锁实现特点意味着：如果不通过索引条件检索数据，那么InnoDB将对表中的所有记录加锁，实际效果跟表锁一样。
（1）在不通过索引条件查询时，InnoDB会锁定表中的所有记录。
（2）Mysql的行锁是针对索引加的锁，不是针对记录加的锁，所以虽然是访问不同行的记录，但是如果使用相同的索引键，是会出现冲突的。
（3）当表有多个索引的时候，不同的事务可以使用不同的索引锁定不同的行，但都是通过行锁来对数据加锁。
优点：
1、支持事务处理、ACID事务特性；
2、实现了SQL标准的四种隔离级别（ 原子性（ Atomicity ）、一致性（ Consistency ）、隔离性（Isolation ）和持续性（Durability ））；
3、支持行级锁和外键约束；
4、可以利用事务日志进行数据恢复。
5、锁级别为行锁，行锁优点是适用于高并发的频繁表修改，高并发是性能优于 MyISAM。缺点是系统消耗较大。
6、索引不仅缓存自身，也缓存数据，相比 MyISAM 需要更大的内存。
缺点：
因为它没有保存表的行数，当使用COUNT统计时会扫描全表。
使用场景：
(1)可靠性要求比较高，或者要求事务；(2)表更新和查询都相当的频繁，并且表锁定的机会比较大的情况。
2、 MyISAM存储引擎
MySQL<= 5.5 MySQL默认的存储引擎。ISAM：Indexed Sequential Access Method(索引顺序存取方法)的缩写，是一种文件系统。擅长与处理，高速读与写。
功能：
（1）支持数据压缩存储,但压缩后的表变成了只读表，不可写；如果需要更新数据，则需要先解压后更新。
（2）支持表级锁定，不支持高并发；
（3）支持并发插入。写 *** 作中的插入 *** 作，不会阻塞读 *** 作（其他 *** 作）；
优点：
1.高性能读取；
2.因为它保存了表的行数，当使用COUNT统计时不会扫描全表；
缺点：
1、锁级别为表锁，表锁优点是开销小，加锁快；缺点是锁粒度大，发生锁冲动概率较高，容纳并发能力低，这个引擎适合查询为主的业务。
2、此引擎不支持事务，也不支持外键。
3、INSERT和UPDATE *** 作需要锁定整个表；
使用场景：
(1)做很多count 的计算；(2)插入不频繁，查询非常频繁；(3)没有事务。
InnoDB和MyISAM一些细节上的差别：
1、InnoDB不支持FULLTEXT类型的索引，MySQL5.6之后已经支持（实验性）。
2、InnoDB中不保存表的 具体行数，也就是说，执行select count() from table时，InnoDB要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。注意的是，当count()语句包含 where条件时，两种表的 *** 作是一样的。
3、对于AUTO_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中，可以和其他字段一起建立联合索引。
4、DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。
5、LOAD TABLE FROM MASTER *** 作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性（例如外键）的表不适用。
6、另外，InnoDB表的行锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表。
1．索引概述
利用关键字，就是记录的部分数据（某个字段，某些字段，某个字段的一部分），建立与记录位置的对应关系，就是索引。索引的关键字一定是排序的。索引本质上是表字段的有序子集，它是提高查询速度最有效的方法。一个没有建立任何索引的表，就相当于一本没有目录的书，在每次查询时就会进行全表扫描，这样会导致查询效率极低、速度也极慢。如果建立索引，那么就好比一本添加的目录，通过目录的指引，迅速翻阅到指定的章节，提升的查询性能，节约了查询资源。
2．索引种类
从索引的定义方式和用途中来看：主键索引，唯一索引，普通索引，全文索引。
无论任何类型，都是通过建立关键字与位置的对应关系来实现的。索引是通过关键字找对应的记录的地址。
以上类型的差异：对索引关键字的要求不同。
关键字：记录的部分数据（某个字段，某些字段，某个字段的一部分）。
普通索引,index：对关键字没有要求。
唯一索引,unique index：要求关键字不能重复。同时增加唯一约束。
主键索引,primary key：要求关键字不能重复，也不能为NULL。同时增加主键约束。
全文索引,fulltext key：关键字的来源不是所有字段的数据，而是从字段中提取的特别关键词。
PS：这里主键索引和唯一索引的区别在于：主键索引不能为空值，唯一索引允许空值；主键索引在一张表内只能创建一个，唯一索引可以创建多个。主键索引肯定是唯一索引，但唯一索引不一定是主键索引。
3.索引原则
如果索引不遵循使用原则，则可能导致索引无效。
（1）列独立
如果需要某个字段上使用索引，则需要在字段参与的表达中，保证字段独立在一侧。否则索引不会用到索引, 例如这条sql就不会用到索引:select * from A where id+1=10
（2）左原则
Like：匹配模式必须要左边确定不能以通配符开头。例如:select * from A where name like '%小明%' ，不会用到索引，而select * from A where name like '小明%' 就可以用到索引（name字段有建立索引），如果业务上需要用到'%小明%'这种方式,有两种方法:1.可以考虑全文索引,但mysql的全文索引不支持中文；2.只查询索引列或主键列,例如:select name from A where name like '%小明%' 或 select id from A where name like '%小明%' 或 select id,name from A where name like '%小明%' 这三种情况都会用到name的索引
复合索引：一个索引关联多个字段，仅仅针对左边字段有效果，添加复合索引时，第一个字段很重要，只有包含第一个字段作为查询条件的情况才会使用复合索引(必须用到建索引时选择的第一个字段作为查询条件,其他字段的顺序无关),而且查询条件只能出现and拼接,不能用or,否则则无法使用索引.
（3）OR的使用
必须要保证 OR 两端的条件都存在可以用的索引，该查询才可以使用索引。
（4）MySQL智能选择
即使满足了上面说原则，MySQL也能弃用索引，例如：select * from A where id >1这里弃用索引的主要原因：查询即使使用索引，会导致出现大量的随机IO，相对于从数据记录的第一条遍历到最后一条的顺序IO开销，还要大。
4.索引的使用场景
（1）索引检索：检索数据时使用索引。
（2）索引排序: 如果order by 排序需要的字段上存在索引，则可能使用到索引。
（3）索引覆盖: 索引拥有的关键字内容，覆盖了查询所需要的全部数据，此时，就不需要在数据区获取数据，仅仅在索引区即可。覆盖就是直接在索引区获取内容，而不需要在数据区获取。例如: select name from A where name like '小明%'
建立索引索引时，不能仅仅考虑where检索，同时考虑其他的使用场景。（在所有的where字段上增加索引，就是不合理的）
5.前缀索引
前缀索引是建立索引关键字一种方案。通常会使用字段的整体作为索引关键字。有时，即使使用字段前部分数据，也可以去识别某些记录。就比如一个班级里，我要找王xx，假如姓王的只有1个人，那么就可以建一个关键字为'王'的前缀索引。语法：Index `index_name` (`index_field`(N))使用index_name前N个字符建立的索引。
6.索引失效
（1） 应尽量避免在 where 子句中使用 != 或 > *** 作符，否则将引擎放弃使用索引而进行全表扫描；
（2） 应尽量避免在 where 子句中使用 or 来连接条件，如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描；
（3） 应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描；
（4）应尽量避免在 where 子句中对字段进行表达式 *** 作，这将导致引擎放弃使用索引而进行全表扫描；如select id from t where num/2 = 100；
（5） 应尽量避免在where子句中对字段进行函数 *** 作，这将导致引擎放弃使用索引而进行全表扫描；如：select id from t where substring(name,1,3) = ’abc’ ；
（6）应尽量避免在where子句中对字段进行类型转换，这将导致引擎放弃使用索引而进行全表扫描； 如果列类型是字符串，那一定要在条件中将数据使用引号引用起来,如select id from t where id = 1；如果id字段在表设计中是varchar类型，那么即使id列上存的是数字，在查询时也一定要用varchar去匹配，sql应改为select id from t where id = '1'；
（7）应尽量避免在where子句中单独引用复合索引里非第一位置的索引；
join 的两种算法：BNL 和 NLJ
NLJ（Nested Loop Join）嵌套循环算法；以如下 SQL 为例：
select * from t1 join t2 on t1.a=t2.a
SQL 执行时内部流程是这样的：
1. 先从 t1（假设这里 t1 被选为驱动表）中取出一行数据 X；
2. 从 X 中取出关联字段 a 值，去 t2 中进行查找，满足条件的行取出；
3. 重复1、2步骤，直到表 t1 最后一行循环结束。
这就是一个嵌套循环的过程，如果在被驱动表上查找数据时可以使用索引，总的对比计算次数等于驱动表满足 where 条件的行数。假设这里 t1、t2都是1万行，则只需要 1万次计算，这里用到的是Index Nested-Loops Join（INLJ，基于索引的嵌套循环联接）。
如果 t1、t2 的 a 字段都没有索引，还按照上述的嵌套循环流程查找数据呢？每次在被驱动表上查找数据时都是一次全表扫描，要做1万次全表扫描，扫描行数等于 1万+1万*1万，这个效率很低，如果表行数更多，扫描行数动辄几百亿，所以优化器肯定不会使用这样的算法，而是选择 BNL 算法；
BNLJ（Block Nested Loop Join）块嵌套循环算法；
1. 把 t1 表（假设这里 t1 被选为驱动表）满足条件的数据全部取出放到线程的 join buffer 中；
2. 每次取 t2 表一行数据，去 joinbuffer 中进行查找，满足条件的行取出，直到表 t2 最后一行循环结束。
这个算法下，执行计划的 Extra 中会出现 Using join buffer(Block Nested Loop)，t1、t2 都做了一次全表扫描，总的扫描行数等于 1万+1万。但是由于 joinbuffer 维护的是一个无序数组，每次在 joinbuffer 中查找都要遍历所有行，总的内存计算次数等于1万*1万。另外如果 joinbuffer 不够大放不下驱动表的数据，则要分多次执行上面的流程，会导致被驱动表也做多次全表扫描。
BNLJ相对于NLJ的优点在于，驱动层可以先将部分数据加载进buffer，这种方法的直接影响就是将大大减少内层循环的次数，提高join的效率。
例如：
如果内层循环有100条记录，外层循环也有100条记录，这样的话，每次外层循环先将10条记录放到buffer中，内层循环的100条记录每条与这个buffer中的10条记录进行匹配，只需要匹配内层循环总记录数次即可结束一次循环（在这里，即只需要匹配100次即可结束），然后将匹配成功的记录连接后放入结果集中，接着，外层循环继续向buffer中放入10条记录，同理进行匹配，并将成功的记录连接后放入结果集。后续循环以此类推，直到循环结束，将结果集发给client为止。
可以发现，若用NLJ，则需要100 * 100次才可结束，BNLJ则需要100 / block_size * 100 = 10 * 100次就可结束,大大减少了循环次数。
JOIN 按照功能大致分为如下三类：
JOIN、STRAIGHT_JOIN、INNER JOIN（内连接,或等值连接）：取得两个表中存在连接匹配关系的记录。
LEFT JOIN（左连接）：取得左表（table1）完全记录，即是右表（table2）并无对应匹配记录。
RIGHT JOIN（右连接）：与 LEFT JOIN 相反，取得右表（table2）完全记录，即是左表（table1）并无匹配对应记录。
注意：mysql不支持Full join,不过可以通过UNION 关键字来合并 LEFT JOIN 与 RIGHT JOIN来模拟FULL join。
mysql 多表连接查询方式，因为mysql只支持NLJ算法,所以如果是小表驱动大表则效率更高；反之则效率下降；因此mysql对内连接或等值连接的方式做了一个优化,会去判断join表的数据行大小,然后取数据行小的表为驱动表。
INNER JOIN、JOIN、WHERE等值连接和STRAIGHT_JOIN都能表示内连接，那平时如何选择呢？一般情况下用INNER JOIN、JOIN或者WHERE等值连接，因为MySQL 会按照"小表驱动大表的策略"进行优化。当出现需要排序时，才考虑用STRAIGHT_JOIN指定某张表为驱动表。
两表JOIN优化
a.当无order by条件时，根据实际情况，使用left/right/inner join即可，根据explain优化 ；
b.当有order by条件时，如select * from a inner join b where 1=1 and other condition order by a.col；使用explain解释语句；
1）如果第一行的驱动表为a，则效率会非常高，无需优化；
2）否则，因为只能对驱动表字段直接排序的缘故，会出现using temporary，所以此时需要使用STRAIGHT_JOIN明确a为驱动表，来达到使用a.col上index的优化目的；或者使用left join且Where条件中不含b的过滤条件，此时的结果集为a的全集，而STRAIGHT_JOIN为inner join且使用a作为驱动表。注：使用STRAIGHT_JOIN虽然不会using temporary，但也不是一定就能提高效率，如果a表数据远远超过b表，那么有可能使用STRAIGHT_JOIN时比原来的sql效率更低，所以怎么使用STRAIGHT_JOIN，还是要视情况而定。
在使用left join（或right join）时，应该清楚的知道以下几点：
(1). on与 where的执行顺序
ON 条件（“A LEFT JOIN B ON 条件表达式”中的ON）用来决定如何从 B 表中检索数据行。如果 B 表中没有任何一行数据匹配 ON 的条件,将会额外生成一行所有列为 NULL 的数据,在匹配阶段 WHERE 子句的条件都不会被使用。仅在匹配阶段完成以后，WHERE 子句条件才会被使用。它将从匹配阶段产生的数据中检索过滤。
所以我们要注意：在使用Left (right) join的时候，一定要在先给出尽可能多的匹配满足条件，减少Where的执行。
(2).注意ON 子句和 WHERE 子句的不同
即使右表的数据不满足ON后面的条件,也会在结果集拼接一条为NULL的数据行,但WHERE后面的条件不一样,右表不满足WHERE的条件,左表关联的数据也会被过滤掉。
(3).尽量避免子查询，而用join
往往性能这玩意儿，更多时候体现在数据量比较大的时候，此时，我们应该避免复杂的子查询。
（1）in 和 not in 要慎用，如：select id from t where num in(1,2,3)对于连续的数值，能用 between 就不要用 in：select id from t where num between 1 and 3很多时候用 exists 代替 in 是一个好的选择：select num from a where num in(select num from b)用下面的语句替换：select num from a where exists(select 1 from b where num=a.num)
（2）Update 语句，如果只更改1、2个字段，不要Update全部字段，否则频繁调用会引起明显的性能消耗，同时带来大量日志。
（3）join语句,MySQL里面的join是用小表去驱动大表,而由于MySQL join实现的原理就是做循环，比如left join就是对左边的数据进行循环去驱动右边的表,左边有m条记录匹配,右边有n条记录那么就是做m次循环,每次扫描n行数据,总扫面行数是m*n行数据。左边返回的结果集的大小就决定了循环的次数,故单纯的用小表去驱动大表不一定的正确的,小表的结果集可能也大于大表的结果集,所以写join的时候尽可能的先估计两张表的可能结果集,用小结果集去驱动大结果集.值得注意的是在使用left/right join的时候,从表的条件应写在on之后,主表应写在where之后.否则MySQL会当作普通的连表查询；
（4）select count(*) from table；这样不带任何条件的count会引起全表扫描，并且没有任何业务意义，是一定要杜绝的；
（5）select * from t 这种语句要尽量避免，使用具体的字段代替*，更有实际意义，需要什么字段就返回什么字段；
（6）数据量大的情况下，limit要慎用，因为使用limit m，n方式分页时，mysql每次都是查询前m+n条，然后舍弃前m条，所以m越大，偏移量越大，性能就越差。比如：select * from A limit 1000000,20这钟，查询效率就会非常低，当分页的页数大于一定的数量之后，就可以换种方式来分页：select * from A a join （select id from A limit 1000000，20） b on a.id=b.id
MySQL 数据类型细分下来，大概有以下几类：
数值，典型代表为 tinyint,int,bigint 浮点/定点，典型代表为 float,double,decimal 以及相关的同义词 字符串，典型代表为 char,varchar 时间日期，典型代表为 date,datetime,time,timestamp 二进制，典型代表为 binary,varbinary 位类型 枚举类型集合类型
以下内容，我们在另一篇文章介绍
大对象，比如 text,blob json 文档类型 一、数值类型（不是数据类型，别看错了）如果用来存放整数，根据范围的不同，选择不同的类型。以上是几个整数选型的例子。整数的应用范围最广泛，可以用来存储数字，也可以用来存储时间戳，还可以用来存储其他类型转换为数字后的编码，如 IPv4 等。示例 1用 int32 来存放 IPv4 地址，比单纯用字符串节省空间。表 x1，字段 ipaddr，利用函数 inet_aton，检索的话用函数 inet_ntoa。 查看磁盘空间占用，t3 占用最大，t1 占用最小。所以说如果整数存储范围有固定上限，并且未来也没有必要扩容的话，建议选择最小的类型，当然了对其他类型也适用。root@ytt-pc:/var/lib/mysql/3305/ytt# ls -sihl总用量 3.0G3541825 861M -rw-r----- 1 mysql mysql 860M 12月 10 11:36 t1.ibd3541820 989M -rw-r----- 1 mysql mysql 988M 12月 10 11:38 t2.ibd3541823 1.2G -rw-r----- 1 mysql mysql 1.2G 12月 10 11:39 t3.ibd 二、浮点数 / 定点数先说 浮点数，float 和 double 都代表浮点数，区别简单记就是 float 默认占 4 Byte。float(p) 中的 p 代表整数位最小精度。如果 p >24 则直接转换为 double，占 8 Byte。p 最大值为 53，但最大值存在计算不精确的问题。再说 定点数，包括 decimal 以及同义词 numeric，定点数的整数位和小数位分别存储，有效精度最大不能超过 65。所以区别于 float 的在于精确存储，必须需要精确存储或者精确计算的最好定义为 decimal 即可。示例 3创建一张表 y1，分别给字段 f1,f2,f3 不同的类型。mysql-(ytt/3305)->create table y1(f1 float,f2 double,f3 decimal(10,2))Query OK, 0 rows affected (0.03 sec)
三、字符类型字符类型和整形一样，用途也很广。用来存储字符、字符串、MySQL 所有未知的类型。可以简单说是万能类型！
char(10) 代表最大支持 10 个字符存储，varhar(10) 虽然和 char(10) 可存储的字符数一样多，不同的是 varchar 类型存储的是实际大小，char 存储的理论固定大小。具体的字节数和字符集相关。示例 4例如下面表 t4 ，两个字段 c1,c2，分别为 char 和 varchar。mysql-(ytt/3305)->create table t4 (c1 char(20),c2 varchar(20))Query OK, 0 rows affected (0.02 sec)
所以在 char 和 varchar 选型上，要注意看是否合适的取值范围。比如固定长度的值，肯定要选择 char；不确定的值，则选择 varchar。
四、日期类型日期类型包含了 date,time,datetime,timestamp，以及 year。year 占 1 Byte，date 占 3 Byte。
time,timestamp,datetime 在不包含小数位时分别占用 3 Byte,4 Byte,8 Byte；小数位部分另外计算磁盘占用，见下面表格。
请点击输入图片描述
注意：timestamp 代表的时间戳是一个 int32 存储的整数，取值范围为 '1970-01-01 00:00:01.000000' 到 '2038-01-19 03:14:07.999999'；datetime 取值范围为 '1000-01-01 00:00:00.000000' 到 '9999-12-31 23:59:59.999999'。综上所述，日期这块类型的选择遵循以下原则：
1. 如果时间有可能超过时间戳范围，优先选择 datetime。2. 如果需要单独获取年份值，比如按照年来分区，按照年来检索等，最好在表中添加一个 year 类型来参与。3. 如果需要单独获取日期或者时间，最好是单独存放，而不是简单的用 datetime 或者 timestamp。后面检索时，再加函数过滤，以免后期增加 SQL 编写带来额外消耗。4. 如果有保存毫秒类似的需求，最好是用时间类型自己的特性，不要直接用字符类型来代替。MySQL 内部的类型转换对资源额外的消耗也是需要考虑的。
示例 5
建立表 t5，对这些可能需要的字段全部分离开，这样以后写 SQL 语句的时候就很容易了。 当然了，这种情形占用额外的磁盘空间。如果想在易用性与空间占用量大这两点来折中，可以用 MySQL 的虚拟列来实时计算。比如假设 c5 字段不存在，想要得到 c5 的结果。mysql-(ytt/3305)->alter table t5 drop c5, add c5 year generated always as (year(c1)) virtualQuery OK, 1 row affected (2.46 sec)Records: 1 Duplicates: 0 Warnings: 0五、二进制类型
binary 和 varbinary 对应了 char 和 varchar 的二进制存储，相关的特性都一样。不同的有以下几点：
binary(10)/varbinary(10) 代表的不是字符个数，而是字节数。
行结束符不一样。char 的行结束符是 \0，binary 的行结束符是 0x00。
由于是二进制存储，所以字符编码以及排序规则这类就直接无效了。示例 6
来看这个 binary 存取的简单示例，还是之前的变量 @a。
切记！这里要提前计算好 @a 占用的字节数，以防存储溢出。
六、位类型
bit 为 MySQL 里存储比特位的类型，最大支持 64 比特位， 直接以二进制方式存储，一般用来存储状态类的信息。比如，性别，真假等。具有以下特性：
1. 对于 bit(8) 如果单纯存放 1 位，左边以 0 填充 00000001。2. 查询时可以直接十进制来过滤数据。3. 如果此字段加上索引，MySQL 不会自己做类型转换，只能用二进制来过滤。示例 7
创建表 c1, 字段性别定义一个比特位。mysql-(ytt/3305)->create table c1(gender bit(1))Query OK, 0 rows affected (0.02 sec)mysql-(ytt/3305)->select cast(gender as unsigned) 'f1' from c1+------+| f1 |+------+| 0 || 1 |+------+2 rows in set (0.00 sec)
过滤数据也一样，二进制或者直接十进制都行。mysql-(ytt/3305)->select conv(gender,16,10) as gender \ ->from c1 where gender = b'1' +--------+| gender |+--------+| 1 |+--------+1 row in set (0.00 sec) mysql-(ytt/3305)->select conv(gender,16,10) as gender \ ->from c1 where gender = '1'+--------+| gender |+--------+| 1 |+--------+1 row in set (0.00 sec)
其实这样的场景，也可以定义为 char(0)，这也是类似于 bit 非常优化的一种用法。
mysql-(ytt/3305)->create table c2(gender char(0))Query OK, 0 rows affected (0.03 sec)那现在我给表 c1 简单的造点测试数据。
mysql-(ytt/3305)->select count(*) from c1+----------+| count(*) |+----------+| 33554432 |+----------+1 row in set (1.37 sec)把 c1 的数据全部插入 c2。
mysql-(ytt/3305)->insert into c2 select if(gender = 0,'',null) from c1Query OK, 33554432 rows affected (2 min 18.80 sec)Records: 33554432 Duplicates: 0 Warnings: 0两张表的磁盘占用差不多。root@ytt-pc:/var/lib/mysql/3305/ytt# ls -sihl总用量 1.9G4085684 933M -rw-r----- 1 mysql mysql 932M 12月 11 10:16 c1.ibd4082686 917M -rw-r----- 1 mysql mysql 916M 12月 11 10:22 c2.ibd
检索方式稍微有些不同，不过效率也差不多。所以说，字符类型不愧为万能类型。
七、枚举类型
枚举类型，也即 enum。适合提前规划好了所有已经知道的值，且未来最好不要加新值的情形。枚举类型有以下特性：
1. 最大占用 2 Byte。2. 最大支持 65535 个不同元素。3. MySQL 后台存储以下标的方式，也就是 tinyint 或者 smallint 的方式，下标从 1 开始。4. 排序时按照下标排序，而不是按照里面元素的数据类型。所以这点要格外注意。示例 8
创建表 t7。mysql-(ytt/3305)->create table t7(c1 enum('mysql','oracle','dble','postgresql','mongodb','redis','db2','sql server'))Query OK, 0 rows affected (0.03 sec)八、集合类型
集合类型 SET 和枚举类似，也是得提前知道有多少个元素。SET 有以下特点：
1. 最大占用 8 Byte，int64。2. 内部以二进制位的方式存储，对应的下标如果以十进制来看，就分别为 1,2,4,8，...，pow(2,63)。3. 最大支持 64 个不同的元素，重复元素的插入，取出来直接去重。4. 元素之间可以组合插入，比如下标为 1 和 2 的可以一起插入，直接插入 3 即可。示例 9
定义表 c7 字段 c1 为 set 类型，包含了 8 个值，也就是下表最大为 pow(2,7)。
mysql-(ytt/3305)->create table c7(c1 set('mysql','oracle','dble','postgresql','mongodb','redis','db2','sql server'))Query OK, 0 rows affected (0.02 sec)插入 1 到 128 的所有组合。
mysql-(ytt/3305)->INSERT INTO c7WITH RECURSIVE ytt_number (cnt) AS ( SELECT 1 AS cnt UNION ALL SELECT cnt + 1 FROM ytt_number WHERE cnt <pow(2, 7) )SELECT *FROM ytt_numberQuery OK, 128 rows affected (0.01 sec)Records: 128 Duplicates: 0 Warnings: 0九、数据类型在存储函数中的用法
函数里除了显式声明的变量外，默认 session 变量的数据类型很弱，随着给定值的不同随意转换。
示例 10定义一个函数，返回两个给定参数的乘积。定义里有两个变量，一个是 v_tmp 显式定义为 int64，另外一个 @vresult 随着给定值的类型随意变换类型。
简单调用下。
mysql-(ytt/3305)->select ytt_sample_data_type(1111,222) 'result'+--------------------------+| result |+--------------------------+| The result is: '246642'. |+--------------------------+1 row in set (0.00 sec)总结
本篇把 MySQL 基本的数据类型做了简单的介绍，并且用了一些容易理解的示例来梳理这些类型。我们在实际场景中，建议选择适合最合适的类型，不建议所有数据类型简单的最大化原则。比如能用 varchar(100)，不用 varchar(1000)。
数据库作为应用开发中必不缺少的基础设施，其性能直接影响应用的整体运行速度。MySQL是目前最广泛使用的关系型数据库之一，对于开发人员写出性能良好的SQL是必备的基本技能之一。下面简单描述下编写SQL的注意事项。
编写高质量的SQL需要从以下几个方面注意，基本原则、表字段注意事项、索引使用注意事项、SQL注意事项。
基本原则
一、尽量不要在数据库里做运算。如果遇到运算尽可能在应用程序层进行计算。
二、控制数据库表数量、控制单表数据量、控制表的字段数。建议单库不要超过四百张表，建议单表字段不要超过五十个，建议单表的数据量不要超过一千万。
三、不要编写大SQL、不要使用大事务。SQL尽量写的简单点拒绝编写大SQL，可以将大SQL拆分成多个小SQL，在应用层聚合。大事务拆分成多个小事务，快速提交。
表字段注意事项
一、选择合适数值字段类型。能用小字段类型的就用小字段类型，如tinyint就比int(1)在表示小数据时合适。
二、能用数字表示就不要用字符。如可以用无符号INT存储IP而不是字符串表示。
三、避免使用NULL字段。原因NULL字段查询优化难，含NULL复合索引失效。
四、少用或拆分TEXT/BLOB字段。字段太大需要更多的空间，性能低下，如需使用拆分到单独表。
五、不要在表字段中存储图片。
索引使用注意事项
一、合理添加索引。索引添加太多会影响更新速度。能够使用复合索引的避免加多个单独索引。
二、字符字段建立前缀索引。
三、不在索引列做运算。索引列做运算会导致索引失效。
四、尽量不使用外建。
SQL类注意事项
一、 SQL语句尽可能简单。大SQL拆分成多个小SQL。
二、事务编写尽量短小。事务即开即用用完立即关闭。
三、尽量不要使用select *。只取需要的列。
四、改写OR为IN或者改写为UNION *** 作。OR在数据量大的时候性能低于IN。
五、避免NOT、!=、>、NOT IN、NOT EXISTS、NOT LIKE等查询。
六、避免%前缀模糊查询。
七、能用UNION ALL不要用UNION。
八、GROUP BY中去除排序。自带排序。
九、同类型的字段做比较。字符类和字符类比较，数值类和数值类比较，不要混在一起比较。
十、尽量单表查询，尽量不要多表关联查询。多表关联查询可以拆分成单表查询在应用程序中聚合数据。
十一、复合索引的多列注意最左原则。
上述注意事项能避免很多性能低下的SQL，希望在开发过程中能引起注意。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）