mysql表很大sum不全

mysql表很大sum不全的解决办法：

1、优化sql和索引。

2、加缓存，memcached，redis。

3、以上都做了后，还是慢，就做主从复制或主主复制，读写分离，可以在应用层做，效率高，也可以用三方工具，第三方工具推荐360的atlas，其它的要么效率不高，要么没人维护。

4、以上都做了还是慢，不要想着去做切分，mysql自带分区表，先试试这个，对应用是透明的，无需更改代码，sql语句是需要针对分区表做优化的，sql条件中要带上分区条件的列，从而使查询定位到少量的分区上，否则就会扫描全部分区。

5、以上都做了，那就先做垂直拆分，其实就是根据模块的耦合度，将一个大的系统分为多个小的系统，也就是分布式系统。

6、水平切分，针对数据量大的表，这一步最麻烦，最能考验技术水平，要选择一个合理的shardingkey，为了有好的查询效率，表结构也要改动，做一定的冗余，应用也要改，sql中尽量带shardingkey，将数据定位到限定的表上去查，而不是扫描全部的表。

随着业务的不断发展，数据库中的数据会越来越多，相应地，单表的数据量也会越到越大，大到一个临界值，单表的查询性能就会下降。

这个临界值，并不能一概而论，它与硬件能力、具体业务有关。

虽然在很多 MySQL 运维规范里，都建议单表不超过 500w、1000w。

但实际上，我在生产环境，也见过大小超过 2T，记录数过亿的表，同时，业务不受影响。

单表过大时，业务通常会考虑两种拆分方案：水平切分和垂直切分。

水平切分，拆分的维度是行，一般会根据某种规则或算法将表中的记录拆分到多张表中。

拆分后的表既可在一个实例，也可在多个不同实例中。如果是后者，又会涉及到分布式事务。

垂直切分，拆分的维度是列，一般是将列拆分到多个业务模块中。这种拆分更多的是上层业务的拆分。

从改造的复杂程度来说，前者小于后者。

所以，在单表数据量过大时，业界用得较多的还是水平拆分。

常见的水平拆分方案有：分库分表、分区表。

虽然分库分表是一个比较彻底的水平拆分方案，但一方面，它的改造需要一定的时间；另一方面，它对开发的能力也有一定的要求。相对来说，分区表就比较简单，也无需业务改造。

很多人可能会认为 MySQL 的优势在于 OLTP 应用，对于 OLAP 应用就不太适合，所以，也不太推荐分区表这种偏 OLAP 的特性。

但实际上，对于某些业务类型，还是比较适合使用分区表的，尤其是那些有明显冷热数据之分，且数据的冷热与时间相关的业务。

下面，我们看看分区表的优点：

遗憾的是，MySQL 分区表不支持并行查询。理论上，当一个查询涉及到多个分区时，分区与分区之间应进行并行查询，这样才能充分利用多核 CPU 资源。

但 MySQL 并不支持，包括早期的官方文档，也提到了这个问题，也将这个功能的实现放到了优先级列表中。

在 MySQL 5.7 中，对于分区表，有个很重大的更新，即 InnoDB 存储引擎原生支持了分区，无需再通过 ha_partition 接口来实现。

所以，在 MySQL 5.7 中，如果要创建基于 MyISAM 存储引擎的分区表，会提示 warning 。

而在 MySQL 8.0 中，则更为彻底，server 层移除了 ha_partition 接口代码。

如果要使用分区表，只能使用支持原生分区的存储引擎。在 MySQL 8.0 中，就只有 InnoDB。

这就意味着，在 MySQL 8.0 中，如果要创建 MyISAM 分区表，基本上就不可能了。

这也从另外一个角度说明了为什么生产上不建议使用 MyISAM 表。

在使用分区表时，大家常常会碰到下面这个报错。

即分区键必须是主键的一部分。

上面的 opr 是一张 *** 作流水表。其中，opr_no 是 *** 作流水号，一般都会被设置为主键，opr_date 是 *** 作时间。基于 *** 作时间来进行分区，是一个常见的分区场景。

为了突破这个限制，可将 opr_date 作为主键的一部分。

但是这么创建，又会带来一个新的问题，即对于同一个 opr_no ，可插入到不同分区中。如下所示：

这实际上违背了业务对于 opr_no 的唯一性要求。

既然这样，有的童鞋会建议给 opr_no 添加个唯一索引，But，现实是残酷的。

即便是添加唯一索引，分区键也必须包含在唯一索引中。

总而言之，对于 MySQL 分区表，无法从数据库层面保证非分区列在表级别的唯一性，只能确保其在分区内的唯一性。

这也是 MySQL 分区表所为人诟病的地方之一。

但实际上，这个锅让 MySQL 背并不合适，对于 Oracle 索引组织表（ InnoDB 即是索引组织表），同样也有这个限制。

Oracle 官方文档（ http://docs.oracle.com/cd/E11882_01/server.112/e40540/schemaob.htm#CNCPT1514），在谈到索引组织表（Index-Organized Table，简称 IOT）的特性时，就明确提到了 “分区键必须是主键的一部分”。

下面，我们看看刚开始的建表 SQL ，在 Oracle 中的执行效果。

同样报错。

注意，这里指定了 ORGANIZATION INDEX ，创建的是索引组织表。

看来，分区键必须是主键的一部分并不是 MySQL 的限制，而是索引组织表的限制。

之所以对索引组织表有这样的限制，个人认为，还是基于性能考虑。

假设分区键和主键是两个不同的列，在进行插入 *** 作时，虽然也指定了分区键，但还是需要扫描所有分区才能判断插入的主键值是否违反了唯一性约束。这样的话，效率会比较低下，违背了分区表的初衷。

而对于堆表则没有这样的限制。

在堆表中，主键和表中的数据是分开存储的，在判断插入的主键值是否违反唯一性约束时，只需利用到主键索引。

但与 MySQL 不一样的是，Oracle 实现了全局索引，所以针对上面的，同一个 opr_no，允许插入到不同分区中的问题，可通过全局唯一索引来规避。

但 MySQL 却无能为力，之所以会这样，是因为 MySQL 分区表只实现了本地分区索引（Local Partitioned Index），而没有实现 Oracle 中的全局索引（Global Index）。

本地分区索引和全局索引的原理图如下所示：

结合原理图，我们来看看两种索引之间的区别：

1. MySQL 分区表关于“分区键必须是唯一键（主键和唯一索引）的一部分”的限制，本质上是索引组织表的限制。

2. MySQL 分区表只实现了本地分区索引，没有实现全局索引，所以无法保证非分区列的全局唯一。

如果要保证非分区列的全局唯一，只能依赖业务实现了。

3. 不推荐使用 MyISAM 分区表。当然，任何场景都不推荐使用 MyISAM 表。

分区

分区就是把一个数据表的文件和索引分散存储在不同的物理文件中。

mysql支持的分区类型包括Range、List、Hash、Key，其中Range比较常用：

RANGE分区：基于属于一个给定连续区间的列值，把多行分配给分区。

LIST分区：类似于按RANGE分区，区别在于LIST分区是基于列值匹配一个离散值集合中的某个值来进行选择。

HASH分区：基于用户定义的表达式的返回值来进行选择的分区，该表达式使用将要插入到表中的这些行的列值进行计算。这个函数可以包含MySQL 中有效的、产生非负整数值的任何表达式。

KEY分区：类似于按HASH分区，区别在于KEY分区只支持计算一列或多列，且MySQL服务器提供其自身的哈希函数。必须有一列或多列包含整数值。

分表

分表和分区类似，区别是，分区是把一个逻辑表文件分成几个物理文件后进行存储，而分表则是把原先的一个表分成几个表。进行分表查询时可以通过union或者视图。

分表又分垂直分割和水平分割，其中水平分分割最为常用。水平分割通常是指切分到另外一个数据库或表中 。

---