摘要：
mysql数据库分表后怎么进行分页查询？1.如果只是为了分页，可以考虑这种分表，就是表的id是范围性的，且id是连续的，比如第一张表id是1到10万，第二张是10万到20万，这样分... mysql数据库分表后怎么进行分页查询？
1.如果只是为了分页，可以考虑这种分表，就是表的id是范围性的，且id是连续的，比如第一张表id是1到10万，第二张是10万到20万，这样分页应该没什么问题。
2.如果是其他的分表方式，建议用sphinx先建索引，然后查询分页，我们公司现在就是这样干的
mysql分表原理？
MySQL 的分表原理是将单张表按照一定的规则进行水平切分成多个小表，以提高数据查询效率。
这些小表通常基于数据的某个维度（例如时间、地理位置、用户 ID 等）进行划分，使得相同维度的数据存储在同一表中，从而减少了表的行数，提高了查询效率。MySQL 支持多种分表方式，例如基于模运算的规则分表、基于聚簇排序的规则分表等。此外，MySQL 还支持主键约束和外键约束等，以确保数据的完整性和一致性。
mysql分区表和分表哪个好？
分表好，MySQL的性能，分表能够改善高并发的性能，分区能够充分利用磁盘的I/O吞吐率。
分表和分区并不矛盾，而是可以相互配合的。对于那些访问量比较大，并且数据量比较多的表，可以采取分表和分区结合的方式(如果MERGE存储引擎的分表方式不能和分区配合的话，也可以使用其他的分表方式)。对于访问量不大，但是数据量比较多的表，可以只采取分区的方式。
谢邀。如果是资产记录表根据常理，首先里边数据应该不能定期清理，根据你现在数据量算上一定增速一个月大概1500-2000千万的数据量。
建议初期可以考虑按月分表或者哈希分表，分区表临时顶下数据量突然增长，当个临时方案用还行，长治久安还是想着做分表吧。
MySQL分库分表之后，id主键如何处理？
我从分库分表存在的问题和怎么做来回答一下这个问题。。
一，分库分表的ID主键不能依赖于数据库的自增，因为多库中会重复！
通常使用外接的数据组件获取全局唯一的ID：比如加强型UUID（根据Ip，时间戳等得到）和使用Redis(RedisAtomicLong)和zookeeper的API获取，Twitter的雪花算法等等！
二，分库分表之后的连接查询比较困难！
问题没法避免，通常拆分SQL，使用多次查询，用查到的结果再分别查别的结果！
三，分布式事务的数据一致性很难保证！
可以使用TCC编程模型保证两处的事务都能正确提交，但是这种方式对代码的侵入比较重！也可以使用基于消息的数据一致性保证！
四，多数据的排序，分组，统计会比较困难！
1，用多线程，对多个节点分别查询，然后汇总！
2，也可以提前冗余查询表，将所有的经常查询的重点数据提前统一到个库表里！
分库分表涉及到的知识点比较多，建议使用专门的分库分表组件！本人有mycat使用经验，如果您有相关问题，欢迎前来探讨！
数据库在做了分库分表之后，关于ID主键，我认为需要考虑这几点：
生成算法
当我们的数据库是单台的时候，是不用太操心主键的生成，但是当数据库进行了分库分表之后，那么主键的生成就需要注意了，至少不能使用数据库内部的自增长序列了，通常要引入分布式唯一标识码的生成算法。
利用数据库生成：先说最笨的方法，利用数据库的自增长序列生成，数据库内唯一，有人会说，刚说完不能用数据库的自增长序列，这么快就要被打脸了么？其实这个的意思是，先利用（额外）的一台数据库，通过其自增长序列得到主键，然后作为分库分表的主键；
利用Redis/MongoDB/zookeeper生成：Redis的单线程的，利用incr和increby；MongoDB的ObjectId；ZK通过znode数据版本；都可以生成全局的唯一标识码；
UUID：生成唯一标识码最常用的算法之一；
Snowflake：Twitter开源，基于zk，41位时间戳（毫秒数）+10位机器的ID+12位毫秒内的流水号+1位符号位（永远是0）；
UidGenerator：百度开源，基于snowflake算法；
Leaf：美团开源，能保证全局唯一性、高可用、趋势递增（不太安全，比如泄露公司订单数量）、单调递增等。
扩容会比较麻烦
分库分表通常的方案都用主键mod分表的数量，来把数据路由到某一个数据库分片上。例如分了10张表，那么就是ID%10，得到结果0-9，代表不同的表；但是当数据量进一步增多的时候，单库的数据量达到了一定的级别之后，那么就需要分更多的表，那么这时候有哪些处理方案呢？
做数据迁移：最简单暴力，也是最麻烦的一个方案；因为当分表（分库）数量增多的时候，因为分片规则的变化，每个表的数据都要被重新分配到多个新的表；
如果id是一个增长的全局序列，当前有十张表，那么分表的算法为：id%10，根据0-9路由到10个表中；当表扩到20张的时候，扩容那一刻取max_id，那么未来分库的算法也就变成了：
if(id<max_id){id%10} else {id%20};
有些分表的算法本身就带时间戳，可以基于id中的时间戳来实现，比如Snowflake算法（见上文），这个算法是一个64位的Long值，前42位就是一个精确到毫秒的时间戳，那么我们的分库算法也就可以以某个时间点来判断：
if(id中的时间<增加分表那一刻的时间){id%10} else {id%20};
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
