SQL性能问题.现在表设计可以把一个大表按类型（各类型字段不相同）拆分成多个小表.拆分后比较方便.

Posted 2023-04-07

问题是.查询的时候查询一个大表和多个小表有误性能差异（各小表查询没有关联关系）？

参考技术A 在数据量大的情况下是有性能差异的，多个小表相当于对大表进行了数据分片，所以不用访问所有大表的数据就可以返回结果。
但在数据量小的情况下使用索引扫描性能差异很小。
小表的另一个问题是如果需要在大表上执行全表查询，即跨小表的查询，则小表的数据结构处理可能比较麻烦。追问

小表的数据结构处理可能比较麻烦------指的是什么？
昨天正好测试了下。2个小表查询（各表1W条数据） 和直接一个大表（2W）条数据。没有差异。。

追答

小表的数据结构处理可能比较麻烦,指的是在有些业务逻辑需要查询覆盖多个小表的数据，且无法确定要访问那些小表的时候，查询语句不好写。
1W条数据是很小的量，看不出来差异的，有索引的话访问代价是相同的，一般小表要达到百万级，打表千万级数据量才有差异的

MySQL面试题之如何优化一条有问题的SQL语句？

如何优化一条有问题的sql语句？

针对sql语句的优化。我们可以从如下几个角度去分析

1. 回归到表的设计层面，数据类型选择是否合理

2. 大表碎片的整理是否完善

3. 表的统计信息，是不是准确的

4. 审查表的执行计划，判断字段上面有没有合适的索引

5. 针对索引的选择性，建立合适的索引（就又涉及到大表DDL的操作问题）

我们看第一点：数据类型要选取合适一些才好。

1）比如建议使用int来存储ipv4的类型，然后通过函数转换。例如：

mysql> select inet_aton(‘172.31.30.62‘);
+---------------------------+
| inet_aton(‘172.31.30.62‘) |
+---------------------------+
|                2887720510 |
+---------------------------+
1 row in set (0.00 sec)

mysql> select inet_ntoa(2887720510);
+-----------------------+
| inet_ntoa(2887720510) |
+-----------------------+
| 172.31.30.62          |
+-----------------------+
1 row in set (0.00 sec)

2）时间类型可以采用datetime属性，他比timestamp可用范围大，存储空间也从原来的8字节降到了5字节，因此可提高性能。

3）表字符集使用 utf8，必要时可申请使用 utf8mb4 字符集。

它的通用性比 gbk，latin1 都要好。utf8 字符集存储汉字占用 3 个字节，如果遇到表情存储的要求，就可以使用 utf8mb4

4） select 查询表的时候只需要获取必要的字段，避免使用 select *。

这样可以减少网络带宽消耗，还有可能利用到覆盖索引

5）所有字段定义中，默认都加上 not null 约束，避免出现 null。

在对该字段进行 select count() 统计计数时，可以让统计结果更准确，因为值为 null 的数据，不会被计算进去的。

6）SQL语句中，尽量避免出现 or 子句

这种判断的子句可以让程序自行完成，不要交给数据库判断。也要避免使用 union，尽量采用 union all，减少了去重和排序的工作。