这是一个创建于 1490 天前的主题，其中的信息可能已经有所发展或是发生改变。
现在有两张表，一张工商表 6000 万数据，一张工商变更记录表 1.5 亿数据，工商表和变更记录表是一对多的关系，没有物理外键
需要用工商 6000 万的表同步一张新的表，
在同步的过程中需要去查变更记录表，算一些衍生数据，现在就是批量查变更记录表特别慢，
传 1 万个“公司 id”去变更记录表都查要十几分钟，“公司 id”在变更记录表已经建了索引，但是还是慢
已经尝试过分表，“公司 id”去 hash 分表 查询速度不是很明显
需要用工商 6000 万的表同步一张新的表，
在同步的过程中需要去查变更记录表，算一些衍生数据，现在就是批量查变更记录表特别慢，
传 1 万个“公司 id”去变更记录表都查要十几分钟，“公司 id”在变更记录表已经建了索引，但是还是慢
已经尝试过分表，“公司 id”去 hash 分表 查询速度不是很明显
第 1 条附言 2021-09-14 17:20:38 +08:00
传 1 万个“公司 id”去变更记录表都查要十几分钟，
纠正一下应该是 1 万个“公司 id” 查需要 2 分钟，
纠正一下应该是 1 万个“公司 id” 查需要 2 分钟，
第 2 条附言 2021-09-14 17:23:18 +08:00
工商表
company_id 主键
name
.....
工商变更记录
rec_id 主键
company_id 普通索引
modification
....
company_id 主键
name
.....
工商变更记录
rec_id 主键
company_id 普通索引
modification
....
第 3 条附言 2021-09-15 13:36:19 +08:00
感谢各位的回答，最后我决定用 MongoDB 作为中间表，先把 1.5 亿的表有需要的数据同步到 MongoDB，
不去查 1.5 亿的表，而是查 MongoDB 的表
不去查 1.5 亿的表，而是查 MongoDB 的表
第 4 条附言 2021-09-23 11:26:53 +08:00
做一个小的总结
MongoDB 分布式解决了目前这个亿级数据的查询，MongoDB 分布式有自动分片，加上查询方面比 MySQL 快太多了不是一个数量级的，之前在 MySQL 通过 id 来查数据，1W 个 id 分批次 1000， 查 10 次（ 1.5 亿数据的表） MySQL 差不多需要 2 分钟，现在换成 MongoDB 分部署并且分片，查 1W id 基本是秒级就能返回
最后说一下，如果只是单纯的查数据没有太多关联操作，可以使用 MongoDB，速度有质的飞跃
MongoDB 分布式解决了目前这个亿级数据的查询，MongoDB 分布式有自动分片，加上查询方面比 MySQL 快太多了不是一个数量级的，之前在 MySQL 通过 id 来查数据，1W 个 id 分批次 1000， 查 10 次（ 1.5 亿数据的表） MySQL 差不多需要 2 分钟，现在换成 MongoDB 分部署并且分片，查 1W id 基本是秒级就能返回
最后说一下，如果只是单纯的查数据没有太多关联操作，可以使用 MongoDB，速度有质的飞跃
 | 1 ipwx 2021-09-14 11:13:13 +08:00 加内存，用内存数据结构做。 这可能是最容易的优化方法 |
 | 2 wzq001 2021-09-14 11:39:11 +08:00 传 1 万个“公司 id”去变更记录表都查要十几分钟 |
| 3 wzq001 2021-09-14 11:40:25 +08:00 ??? 业务需要批量变更数据？能不能单独的变更 |
 | 4 yidinghe 2021-09-14 11:40:51 +08:00 via Android 试下 elastic search，将计算负担分流到多个节点 |
 | 5 saberlong 2021-09-14 12:07:20 +08:00 via Android 分片。把两张表拉下来，根据公司 id 分片，存到磁盘上。然后一个一个分片加载到内存中计算。磁盘持久化的 b+树上千万级，性能下降很厉害。 |
 | 6 ericbize 2021-09-14 12:17:03 +08:00 via iPhone 不说说什么硬件么 |
 | 7 zoharSoul 2021-09-14 12:19:34 +08:00 不说说什么硬件么 正常来说 1w 个公司 id 去查记录表应该是秒出 |
 | 8 goobai 2021-09-14 12:51:40 +08:00 via Android 数据同步到 es，然后再查 |
 | 9 qq8331199 OP |
 | 11 feirenK 2021-09-14 14:46:35 +08:00 hbase |
| 12 feirenK 2021-09-14 14:47:12 +08:00 ck |
 | 13 ytmsdy 2021-09-14 14:57:51 +08:00 贴一下执行计划，这样大家可以集思广益的看一看。 |
 | 14 zhengsidao 2021-09-14 15:01:54 +08:00 用 es 去查实际上是比较快，1.5 亿的数据量很少，term query 很快就能找到。 不过就算是用什么来存储 一万个 id 要查十几分钟，你们到底怎么存的，会这么慢 |
 | 15 tulumu 2021-09-14 15:07:27 +08:00 可以试试实时计算行不行 1. 变更表 binlog 实时更新到 kv 存储中(redis/hbase) 2. 接入主表 binlog, flink 实时 lookup 或者 lookup 缓存 来关联变更维表(redis/hbase), do something, 产生你想要的逻辑的新表 |
 | 16 G64q9J89mN5KSgmE 2021-09-14 15:33:37 +08:00 上 clickhouse |
 | 17 tiiis 2021-09-14 15:48:28 +08:00 mysql ？ 看看索引有没又生效哦，我们几十亿数据 mysql 分好表做好索引也可以毫秒级别的 |
 | 18 aragakiyuii 2021-09-14 16:04:42 +08:00 数据库，表结构，索引都是什么？ 这些不知道的话挺难想思路的。。。 |
| 19 ericbize 2021-09-14 16:36:27 +08:00 什么数据库？ mysql 的话 看看 buff pool 是多少啊， 正常 128 G 内存 如果放 两张表 都可以全部进内存了吧 |
 | 20 hongweiliuruige 2021-09-14 16:46:19 +08:00 mysql8.0 |
 | 21 abccccabc 2021-09-14 17:00:31 +08:00 同步一张新的表需要实时吗？不需要的话，走计划任务呗 |
| 22 qq8331199 OP |
| 23 qq8331199 OP @zhengsidao 说错了 1W id 我测试的时候应该有人操作数据库，后面再测了一次 只用 2 分钟，但是还是慢 |
| 24 abccccabc 2021-09-14 17:26:51 +08:00 |
| 25 qq8331199 OP @zhengsidao es 也不太行，1.5 亿的数据是全部需要查的，其实我还要 3 张过亿的表需要查，之前试过全部放 es，一起查这 4 张表，速度并没有很快，还很容易超时 |
| 29 aragakiyuii 2021-09-14 18:54:08 +08:00 via iPhone 1.5 亿表里就算索引生效，读的 block 也太多了 看看这个 https://dev.mysql.com/doc/refman/8.0/en/range-optimization.html#equality-range-optimization |
| 30 aragakiyuii 2021-09-14 19:01:29 +08:00 via iPhone 再给点信息吧字段类型，字段索引，索引类型，还有 explain 的结果 |
| 31 aragakiyuii 2021-09-14 19:03:16 +08:00 via iPhone 或者不如找个内存大的服务器读到内存里去处理 |
| 32 ericbize 2021-09-14 20:29:40 +08:00 via iPhone @qq8331199 先看看是不是 table per file， 如果是的话 你可以试试整理一下？ （可能有卡死的风险）你看看是不是 innodb， 不过建议先让 dba 能不能处理一下先 |
 | 33 aru 2021-09-14 20:47:30 +08:00 上 greenplum 吧，只要你的硬盘性能跟得上，上尽量多的 segment，非常快 |
| 34 qq8331199 OP @aragakiyuii company_id 普通索引 varchar 类型，上面已经说了，explain 显示是走索引的， 你有试过 1.5 亿里面查 1W 数据要多久吗？不是走主键索引，走普通索引 |
Select Language