1.MySQL的“utf8”实际上不是真正的UTF-8“utf8”只支持每个字符最多三个字节，而真正的UTF-8是每个字符最多四个字节。所有在使用“utf8”的MySQL和MariaDB用户都应该改用“utf8mb4”，永远都不要再使用“utf8”。“utf8”只能算是个专有的字符集，它给我们带来了新问题，却一直没有得到解决。
2.正常情况下mysql一张表大约能存储1000万~2000万条数据，超过2000万条一般会需要优化。其实MySQL单表的上限，主要与操作系统支持的最大文件大小有关。InnoDB 存储引擎将InnoDB 表保存在一个表空间内，该表空间可由数个文件创建。这样，表的大小就能超过单独文件的最大容量。表空间可包括原始磁盘分区，从而使得很大的表成为可能。表空间的最大容量为64TB。当然这是理论值，数据容量如果达到1TB以上，一般都会需要特殊手段处理。
3.所谓的"冷热数据"，冷数据一般指访问频率少的数据，热数据一般指访问频率高的数据。
比如说是一个论坛，要不就以贴吧为例吧。用户发的所有的帖子都记录在数据库中，原先是直接一张表，有一个帖子往里加一条记录。然后想着假如说我现在想要获取全部热门贴，就要在如此大范围大数据的一张表中查询并按时间排序吧。于是我就想可不可以说再建一个表，作为一个热数据表，定好里面永远只有100条记录，每当有一个热门贴产生了，就往表里填条记录。然后当已有100条，101条来的时候，就把最初的第一条挤到冷数据表，冷数据表就相当于充当一个存档的功能吧。这样，获取全部热门贴只需要在100个记录中查找，大大缩小了范围。
4.mysql单表吞吐量：MySQL能承受的数据量的多少主要和数据表的结构有关，并不是一个固定的数值。表的结构简单，则能承受的数据量相对比结构复杂时大些。MySQL自己提供的案例：1996年以来，我们一直都在使用MySQL，其环境有超过40个数据库，包含10,000个表，其中500多个表超过7百万行，这大约有100GB的关键应用数据。我们还听说，有些用户将MySQL用于含60000个表和约50亿行的数据库。自己的测试显示：MySQL数据库单表在5千万条记录（10G）情况下运行良好。当然，这些结论和对数据库的优化是分不开的。据D.V.B 团队以及Cmshelp团队做CMS系统评测时的结果来看，MySQL单表大约在2千万条记录（4G）下能够良好运行，经过数据库的优化后5千万条记录（10G）下运行良好。
5.正常表只能存放大概一千万或两千万左右数据，如果有上亿的用户表，则采取横向分割表，然后分布式存储怎样分割比较合适？？可以根据地域，但是根据用户分布的情况来说，还是会有某些地域访问稠密而有些地域比较稀疏的问题。insertdate(插入数据时间)last_update(最后更新时间)reference（备注）status（标识数据库状态）这些控制或者方面数据的字段，主表一般都会带上，从表关联表根据实际情况选择性的带上这些字段。。
6.char (13)长度固定，varchar(13) 可变长。由于char 固定长度，所以在处理速度上要比varchar快速很多，但是对费存储空间，所以对存储不大，但在速度上有要求的可以使用char类型，反之可以用varchar类型来实例。在用char字符类型时内容后面有空间时必须作相关处理，要不就会把空格自动删除。实际上运用算法对数据进行处理的时候，永远离不开"空间"和"时间"的概念。
7.存储引擎：
myisam 存储引擎 建议使用固定长度，数据列代替可变长度的数据列。
memory存储引擎 目前都使用固定数据行存储，因此无论使用char varchar列都没关系。
innodb 存储引擎 建意使用varchar 类型。
8.水平拆分和垂直拆分
垂直拆分：原来一个表的信息，拆分到两个或者多个表中，通过主键来进行关联。对数据库表列（表结构）进行分割
优点：
数据库的拆分简单明了，拆分规则明确；
应用程序模块清晰明确，整合容易；
数据维护方便易行，容易定位；
缺点：
部分表关联无法在数据库级别完成，需要在程序中完成；
单表大数据量仍然存在性能瓶颈；
事务处理相对更为复杂；
切分达到一定程度之后，扩展性会遇到限制。
水平拆分：把一个表的数据按照某种规则划分到不同表或数据库里。（水平拆分行，行数据拆分到不同表中）
优点：
解决单表大数据量性能遇到瓶颈的问题；
应用程序端整体架构改动相对较少；
事务处理相对简单；
只要切分规则能够定义好，基本上较难遇到扩展性限制；
缺点：
切分规则相对更为复杂，很难抽象出一个能够满足整个数据库的切分规则；
后期数据的维护难度有所增加，人为手工定位数据更困难；
应用系统各模块耦合度较高，可能会对后面数据的迁移拆分造成一定的困难。