MySQL中一个库中表数量是否有限制?

一、MySQL中一个库中表数量是否有限制

1.限制那肯定是有的，因为系统数据库的表结构信息存储表，字段为：ID INT UNSIGNED 类型，非常多42亿多一点，但肯定不会超过；

2.主要是文件系统，对同时打开多少个文件有限制性的：2048，但是可以修改内核参数

3.拆分过多最大的坏处，体现在：数据库的维护上面；

4.数据量没达到一定程度，且业务需求不需要，例如：新闻主题表，几百G正常，就可能不必要拆分，但是像新浪这样的公司就必须要拆分。换句话而言就是要看数据量、业务发展趋势、数据的存取需求、数据访问的并发度等综合而考虑；

5.拆分，必然对程序操纵数据的复杂度增大了，为此不得不搞一个通用的数据层，其实在数据量、并发不高、压力不大等情况下，是浪费资源，以及降低处理效率的，只有大数据量、高并发等场景下才是提高；

6.拆分之后，还可能带来隐患点，比如通用数据层，必须考虑单点等问题，同时也可能带来问题排查的难度；

7.大数据量、高并发等场景，准确说应该一般是：垂直拆分+水平拆分，肯定是提供性能、系统负载能力、支持业务增量等；

所以，综合建议大家慎重分析自己所在公司的业务模型，数据增长趋势，技术实力等综合考虑，才是最稳妥的，不要把简单的事情搞复杂了。

延伸阅读：

二、id的一些典型的类型

整型：整型通常来说是优异的选择，这是因为整型的运算和比较都很快，而且还可以设置 AUTO_INCREMENT 属性自动递增。ENUM 和 SET：通常不会选择枚举和集合作为 id，然后对于那些包含有“类型”、“状态”、“性别”这类型的列来说是挺合适的。例如我们需要有一张表存储下拉菜单时，通常会有一个值和一个名称，这个时候值使用枚举作为主键也是可以的。字符串：尽可能地避免使用字符串作为 id，一是字符串占据的空间更大，二是通常会比整型慢。选用字符串作为 id 时，还需要特别注意 MD5、SHA1和 UUID 这些函数。每个值是在很大范围的随机值，没有次序，这会导致插入和查询更慢：插入的时候，由于建立索引是随机位置（会导致分页、随机磁盘访问和聚集索引碎片），会降低插入速度。查询的时候，相邻的数据行在磁盘或内存上上可能跨度很大，也会导致速度更慢。

如果确实要使用 UUID 值，应当移除掉“-”字符，或者是使用 UNHEX 函数将其转换为16字节数字，并使用 BINARY(16)存储。然后可以使用 HEX 函数以十六进制的方式进行获取。UUID 产生的方法有很多，有些是随机分布的，有些是有序的，但是即便是有序的性能也不如整型。