在MySQL中，char、varchar和text类型的字段都可以用来存储字符类型的数据，char、varchar都可以指定最大的字符长度，但text不可以。

它们的存储方式和数据的检索方式也都不一样。

数据的检索效率是：char > varchar > text

具体说明：

char：存储定长数据很方便，CHAR字段上的索引效率级高，必须在括号里定义长度，可以有默认值，比如定义char(10)，那么不论你存储的数据是否达到了10个字节，都要占去10个字节的空间（自动用空格填充），且在检索的时候后面的空格会隐藏掉，所以检索出来的数据需要记得用什么trim之类的函数去过滤空格。

varchar：存储变长数据，但存储效率没有CHAR高，必须在括号里定义长度，可以有默认值。保存数据的时候，不进行空格自动填充，而且如果数据存在空格时，当值保存和检索时尾部的空格仍会保留。另外，varchar类型的实际长度是它的值的实际长度+1，这一个字节用于保存实际使用了多大的长度。

text：存储可变长度的非Unicode数据，最大长度为2^31-1个字符。text列不能有默认值，存储或检索过程中，不存在大小写转换，后面如果指定长度，不会报错误，但是这个长度是不起作用的，意思就是你插入数据的时候，超过你指定的长度还是可以正常插入。

关于存储空间：

在使用UTF8字符集的时候，MySQL手册上是这样描述的：

基本拉丁字母、数字和标点符号使用一个字节；
大多数的欧洲和中东手写字母适合两个字节序列：扩展的拉丁字母（包括发音符号、长音符号、重音符号、低音符号和其它音符）、西里尔字母、希腊语、亚美尼亚语、希伯来语、阿拉伯语、叙利亚语和其它语言；
韩语、中文和日本象形文字使用三个字节序列。

结论：

1、经常变化的字段用varchar；

2、知道固定长度的用char；

3、超过255字节的只能用varchar或者text；

4、能用varchar的地方不用text；

5、能够用数字类型的字段尽量选择数字类型而不用字符串类型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接回逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了；

6、同一张表出现多个大字段，能合并时尽量合并，不能合并时考虑分表 查看全部

聚簇索引

数据库表的索引从数据存储方式上可以分为聚簇索引和非聚簇索引（又叫二级索引）两种。Innodb的聚簇索引在同一个B-Tree中保存了索引列和具体的数据，在聚簇索引中，实际的数据保存在叶子页中，中间的节点页保存指向下一层页面的指针。“聚簇”的意思是数据行被按照一定顺序一个个紧密地排列在一起存储。一个表只能有一个聚簇索引，因为在一个表中数据的存放方式只有一种。

一般来说，将通过主键作为聚簇索引的索引列，也就是通过主键聚集数据。下图展示了Innodb中聚簇索引的结构（图片来自《高性能MySQL(第三版)》）：





 
这里要特别注意页的概念，一个页可以理解为一块具有一定大小的连续的存储区域。相同页内的数据行在物理上是相邻的，因此逻辑上键值相邻的页在物理上可能相隔很远。

在中间的某个节点页中，主键<11的叶子页和11<主键<21的叶子页分别被两个指针所指向，且主键<11的叶子页也有一个指针指向了11<主键<21的叶子页，其余页之间的关系也是一样。

聚簇索引的优点

聚簇索引将索引和数据行保存在同一个B-Tree中，查询通过聚簇索引可以直接获取数据，相比非聚簇索引需要第二次查询（非覆盖索引的情况下）效率要高。
聚簇索引对于范围查询的效率很高，因为其数据是按照大小排列的，


聚簇索引的缺点

聚簇索引的更新代价比较高，如果更新了行的聚簇索引列，就需要将数据移动到相应的位置。这可能因为要插入的页已满而导致“页分裂”。
插入速度严重依赖于插入顺序，按照主键进行插入的速度是加载数据到Innodb中的最快方式。如果不是按照主键插入，最好在加载完成后使用OPTIMIZE TABLE命令重新组织一下表。
聚簇索引在插入新行和更新主键时，可能导致“页分裂”问题。
聚簇索引可能导致全表扫描速度变慢，因为可能需要加载物理上相隔较远的页到内存中（需要耗时的磁盘寻道操作）。


非聚簇索引

非聚簇索引，又叫二级索引。二级索引的叶子节点中保存的不是指向行的物理指针，而是行的主键值。当通过二级索引查找行，存储引擎需要在二级索引中找到相应的叶子节点，获得行的主键值，然后使用主键去聚簇索引中查找数据行，这需要两次B-Tree查找。

总结

下面是Innodb聚簇索引和非聚簇索引的示意图（图片来自《高性能MySQL(第三版)》：




  查看全部