mysql 几种搜索引擎的比较

MySQL5.5以后默认使用InnoDB存储引擎，其中InnoDB和BDB提供事务安全表，其它存储引擎都是非事务安全表
MyISAM
它不支持事务，也不支持外键，尤其是访问速度快，对事务完整性没有要求或者以SELECT、INSERT为主的应用基本都可以使用这个引擎来创建表。
InnoDB
InnoDB存储引擎提供了具有提交、回滚和崩溃恢复能力的事务安全。但是对比MyISAM的存储引擎，InnoDB写的处理效率差一些并且会占用更多的磁盘空间以保留数据和索引

InnoDB和MyISAM的区别：
InnoDB支持事务，支持外键，空间使用和内存使用都比MyISAM高。InnoDB是行级锁。MyISAM是表级锁，InnoDB表能够自动从灾难中恢复，查询不加锁

外键：
1.外键的性能问题

数据库需要维护外键的内部管理；

外键等于把数据的一致性事务实现，全部交给数据库服务器完成；

有了外键，当做一些涉及外键字段的增，删，更新操作之后，需要触发相关操作去检查，而不得不消耗资源；

外键还会因为需要请求对其他表内部加锁而容易出现死锁情况；

MySQL 中 varchar 与 char 的区别？varchar(50) 中的 50 代表的涵义？

varchar 与 char 的区别，char 是一种固定长度的类型，varchar 则是一种可变长度的类型。
varchar(50) 中 50 的涵义最多存放 50 个字符。varchar(50) 和 (200) 存储 hello 所占空间一样，但后者在排序时会消耗更多内存，因为 ORDER BY col 采用 fixed_length 计算 col 长度(memory引擎也一样)。

 int(11) 中的 11 代表什么涵义？
无论是int(3), int(6), 都可以显示6位以上的整数。但是，当数字不足3位或6位时，前面会用0补齐，我看了真实的数据库，并没有补齐啊？

为什么 SELECT COUNT(*) FROM table 在 InnoDB 比 MyISAM 慢？
对于 SELECT COUNT(*) FROM table 语句，在没有 WHERE 条件的情况下，InnoDB 比 MyISAM 可能会慢很多，尤其在大表的情况下。因为，InnoDB 是去实时统计结果，会全表扫描；而 MyISAM 内部维持了一个计数器，预存了结果，所以直接返回即可。

【重点】什么是索引？
索引，类似于书籍的目录，想找到一本书的某个特定的主题，需要先找到书的目录，定位对应的页码。MySQL 中存储引擎使用类似的方式进行查询，先去索引中查找对应的值，然后根据匹配的索引找到对应的数据行。

索引有什么好处？
提高数据的查询速度，降低数据库IO成本
降低数据排序的成本，降低CPU消耗：索引之所以查的快，是因为先将数据排好序，若该字段正好需要排序，则正好降低了排序的成本。

索引有什么坏处？
占用存储空间：索引实际上也是一张表，记录了主键与索引字段，一般以索引文件的形式存储在磁盘上。

降低更新表的速度：表的数据发生了变化，对应的索引也需要一起变更，从而降低的更新速度。否则索引指向的物理数据可能不对，这也是索引失效的原因之一。

索引的使用场景？
对非常小的表，大部分情况下全表扫描效率更高。

对中大型表，索引非常有效。
特大型的表，建立和使用索引的代价随着增长，可以使用分区技术来解决
索引的类型？

索引，都是实现在存储引擎层的。主要有六种类型：

1、普通索引：最基本的索引，没有任何约束。

2、唯一索引：唯一索引列的值必须唯一允许有空值。

3、主键索引：特殊的唯一索引，不允许有空值。

4、复合索引：将多个列组合在一起创建索引，可以覆盖多个列。复合索引遵守“最左前缀”原则，即在查询条件中使用了复合索引的第一个字段，索引才会被使用。因此，在复合索引中索引列的顺序至关重要

5、外键索引：只有InnoDB类型的表才可以使用外键索引，保证数据的一致性、完整性和实现级联操作。
6、全文索引：MySQL 自带的全文索引只能用于 InnoDB、MyISAM ，并且只能对英文进行全文检索，一般使用全文索引引擎。

MySQL 索引的“创建”原则？

1.最适合索引的列是出现在 WHERE 子句中的列，或连接子句中的列，而不是出现在 SELECT 关键字后的列。

2.索引列的基数(索引中不重复的索引值的数量)越大，索引效果越好。

3、根据情况创建复合索引，复合索引可以提高查询效率,因为复合索引的基数会更大。。

4、避免创建过多的索引，索引会额外占用磁盘空间，降低写操作效率。

5、主键尽可能选择较短的数据类型，可以有效减少索引的磁盘占用提高查询效率。

6、对字符串进行索引，应该定制一个前缀长度，可以节省大量的索引空间。

MySQL 索引的“使用”注意事项？

1.应尽量避免在 WHERE 子句中使用 != 或 <> 操作符，否则将引擎放弃使用索引而进行全表扫描。优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行。

2.应尽量避免在 WHERE 子句中使用 OR 来连接条件如：SELECT id FROM t WHERE num = 10 OR num = 20 。要想使用 or，又想让索引生效，只能将 or 条件中的每个列都加上索引。

3、Where 子句里对索引列上有表达式运算，数学运算,函数运算，用不上索引。
4、不要在 WHERE 子句中的 = 左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。

5、如果 MySQL 评估使用索引比全表扫描更慢，会放弃使用索引。如果此时想要索引，可以在语句中添加强制索引。

6、存在索引列的数据类型隐形转换，则用不上索引，比如列类型是字符串，那一定要在条件中将数据使用引号引用起来,否则不使用索引
7、LIKE 查询，% 不能在前，因为无法使用索引。如果需要模糊匹配，可以使用全文索引。
6、复合索引遵循’最左前缀’原则(即在查询条件中使用了复合索引的第一个字段，索引才会被使用。因此，在复合索引中索引列的顺序至关重要)。

mysql常见的水平切分方式有哪些？

回答：分库分表，分区表 

什么是mysql的分库分表？

回答：把一个很大的库（表）的数据分到几个库（表）中，每个库（表）的结构都相同，但他们可能分布在不同的mysql实例，甚至不同的物理机器上，以达到降低单库（表）数据量，提高访问性能的目的。

分库分表往往是业务层实施的，分库分表后，为了满足某些特定业务功能，往往需要rd修改代码。 

什么是mysql的分区表？

回答：所有数据还在一个表中，但物理存储根据一定的规则放在不同的文件中。这个是mysql支持的功能，业务rd代码无需改动。 

看上去分区表很帅气，为什么大部分互联网还是更多的选择自己分库分表来水平扩展咧？

回答：

1）分区表，分区键设计不太灵活，如果不走分区键，很容易出现全表锁

2）一旦数据量并发量上来，如果在分区表实施关联，就是一个灾难

3）自己分库分表，自己掌控业务场景与访问模式，可控。分区表，研发写了一个sql，都不确定mysql是怎么玩的，不太可控  

使用联合索引进行排序或分组的注意事项。
1.对于联合索引有个问题需要注意，ORDER BY的子句后边的列的顺序也必须按照索引列的顺序给出，索引列的顺序是(b,c,d),如果给出 order by c, b, d 的顺序，那也是用不了B+树索引的。
2.对于使用联合索引进行排序的场景，我们要求各个排序列的排序顺序是一致的，也就是要么各个列都是ASC规则 排序，要么都是DESC规则排序。 ORDER BY子句后的列如果不加ASC或者DESC默认是按照ASC排序规则排序的，也就是升序排序的
select * from t1 order by b ASC, c DESC; 这个查询是用不到索引的。

执行过程：
 select * from a where id in (select a_id from b)
mysql 执行过程：首先把in里面的子查询存到临时表，然后join,如果select a_id from b里的a_id 有重复值，会先去重。