这是一个创建于 340 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司某些大表动辄几亿以上的数据量，主管这边已规定不能直接用 sql 查这种大表（不然即便有索引也会直接卡死……），想排查数据可以用 es 操作（因为是从数据库同步到 es ，然后再由代码读取），但是遇到需要排查数据正误的情况时，就需要查取数据库的原数据来分析代码是否存在插入数据不对的问题。
一旦遇到这种情况我就懵逼了，我数据库都没法看我咋个快速找到 BUG 根源？
 |
1
jfds 340 天前
一般查备库
|
 |
2
yingqiuQAQ 340 天前
几个亿的数据不考虑分表，等几十亿的时候再考虑吗(不是)
|
 |
3
cndenis 340 天前
数据库不能查, 那这数据库用来干什么的?
|
 |
4
UnrealEngine OP @yingqiuQAQ #2 没办法，主管说了算，俺只是搬砖滴
|
|
5
UnrealEngine OP @yingqiuQAQ #2 现在即便是用 es 查数据但也经常出现卡顿的问题，不知道是不是数据量也跟着变多的原因
|
 |
6
zoharSoul 340 天前
几个亿 sql 随便查啊
|
 |
7
yufeng0681 339 天前
想办法把数据量变小，
比如多久以前的数据不会再更新了， 那查询备份表就足以； 比如只需要复核最近几个月的数据是否有一致性问题，那弄个新表只存最近几个月的数据（利用数据库日志来做同步更新新表），，查询起来也飞快 |
 |
8
guo4224 339 天前 via iPhone
es 也可以直接用 sql……
|
 |
9
Terry166 339 天前
1 ，优化 sql ，上亿的行数就不要用 join 了，只针对单个表进行查询，查询位于主键索引（聚簇索引）上的列，避免回表。避免用 in （ in 导致查询复杂度提升一个数量级，要用 in 的话最多只能放 1000 个值）；
2 ，分库分表； 3 ，纵向扩展提升机器硬件； 4 ，利用云计算数据仓库技术（ Cloud Data Warehouse platform ），比如 AWS Snowflake ，GCP BigQuery ，或者 Azure Synapse ，把数据库文件导入数据仓库，在查询的时候会自动横向扩展增加机器，查询包含 1000 亿条数据的表也只需要 10 秒左右的时间，费用会根据所查询的列来计算。 |
 |
10
noparking188 339 天前
问主管 binlog 同步哪去了，之前 经历过是用 binlog 同步 HDFS ，Presto 查，千亿数据量
|
 |
11
Tinyang 339 天前
定期 snapshot 回本地数据库，敏感数据脱敏
|
 |
12
crazycarry 339 天前
70 亿的表。。有时间索引还好吧，别作死有统计的，，
|
 |
13
RicherWQ 339 天前
首先上亿数据很常见，目前你们的处理方式问题很多：
1.几亿数据为什么不做分库分表？做了分库分表，都是小表就查呗 2.为什么不让查询？数据库没做主从架构，有了这个架构，查询从库出问题也没啥影响啊 3.主管技术问题？数据再多用 id 查询单条数据也是问题不大的，先通过 es 查到数据的 ID ，再根据 id 去数据库查询呗 |
 |
14
Orlion 339 天前
1. 依靠索引列缩小扫描行数后再进行复杂查询
2. 查备库 |
 |
15
burymme11 339 天前
让运维拉一份出事时间段的 binglog 给你。
|
|
16
Terry166 339 天前 via iPhone
另外用于统计的 query 比如 sum ，average 等，以及 where 子句条件不精确，会导致索引失效，全表扫描，不适合 OLTP 型数据库。
|
 |
17
sampeng 339 天前
都几亿数据了。你要说没备份库我是不信的
|
 |
18
jones2000 339 天前
库不是要同步到 es ， 那就说明 es 同步工具是可以访问数据库的， 把错误的这条记录删了， 然后同步下， 记录同步日志， 把这条同步的记录的内容都打印出来，不就是数据库的内容。
|
Select Language