mysql 分表能带来哪些显著的，可见的提升？

[SJH0402]

前提：
1 、未分库
2 、表 A 年数据量 1000w ，表 B 年数据量 5000w
3 、原业务中的 sql 涉及到 left join 查询，总是超时

两个表都使用 create_time 字段按月份分表 12 个，
在分表后，left join 的查询效率没有丝毫提升，
单表查询效率略微下降 (0.02 秒 > 0.05 秒)？

分表工具使用的是 mycat 以及 sharding-proxy （都有尝试）。

因为是第一次尝试 mysql 分表，所以很疑惑，分表带来的究竟是哪方面的提升？
还是说我的分表字段或者 sql 有问题

[dobelee]

啥场景？干掉 join ，关键字段冗余存储，或者组装数据。从业务的角度优化一下。

[linauror]

查询时带上时间条件了没，如果没带可能比单表效率还差。另外直接去数据库 explain 分析一下命中了索引没

[fkdog]

所以你有确定查询性能已经无任何可优化的手段后才决定分表，
还是瞄了了面经然后感性判断数据量大需要分表然后稀里糊涂的就拆了？

[SJH0402]

@linauror 带了，时间条件是范围索引，甚至有时候还会添加等值查询之类的条件进一步命中索引。哪怕是这样速度也是慢的出奇，几十上百秒是经常的

[SJH0402]

@dobelee 正在往这个方向尝试

[SJH0402]

@fkdog 目前是单表 join 太慢，领导让分表试试，技术这块我只有执行权没有决定权

[boks]

单表查询 0.05 秒，left join 后几十上百秒？你用啥字段关联的，确定都有索引吗

[SJH0402]

@boks 一般来说是 left join 后使用 bigint 类型的 id 类字段进行关联，然后用 create_time 搭配 where 关键字进行范围过滤

select xxx from a left join b
on a.id = b.aid
where create_time between ... and ...

[SJH0402]

@boks 使用 explain 看过，能触发索引

[openliucongbx]

最好是冗余一下,或者做个新表速度杠杠的

[MetalCore]

分表需要围绕索引来, 如果分表前的索引(explain)和分表后的索引是一模一样的, 那肯定不能带来什么提升;
其次分表数据可能不均衡, 使分表没起效果
再次分表可以多分细一些, 每个片要很多大, 建议多测试测试

[themostlazyman]

left join 也是扫 A 的全表吧。

[SJH0402]

@themostlazyman 对，扫 A 表全表。我是以 1000w 条数据作的测试

[SJH0402]

@MetalCore 在页面上的条件查询的两个重要组成是手机号和记录的生成时间，考虑到手机号太多，就用的 create_time,我再查一下看换一个字段会不会更好

[themostlazyman]

你为啥不先用条件把 A 表的范围缩小再去 left join 。

[opengps]

分表当然是因为索引本身足够大，减小索引才变快

[thevita]

分表的作用就是：控制 b+tree 的深度, 让每个 tree 的规模在硬件/系统/业务 能接受的范围内.

方案: 看看 vitess?

[SJH0402]

@themostlazyman 前端页面是个 table 页，默认显示全部数据的前 10 条

[yingqiuQAQ]

1. 大表 Join 小表。2. Join 列类型一致并建立索引。

如果搜索的数据量大，慢是无可厚非的。 但是建议先贴下 explain 的结果，看下 SQL 是不是全是走的索引

[ZephyrW]

两个分表规则一样的话，设置下 binding-tables ，连表查避免笛卡尔积