mysql 单表即将上 2 千万数据 存授权的 性能跟不上了 怎么优化

• 資深大佬 : zoharSoul

  加钱呗
  阿里云 rds 4c8g 的我试过单表 2 亿多数据,
  单表查询没啥压力

• 資深大佬 : cominghome

  @zoharSoul 4c8g 能搞 2 亿行？这么猛的吗？还是说字段少？

• 資深大佬 : Nitromethane

  数据同步到 ES 一份，读请求走 ES ；

• 資深大佬 : peyppicp

  按照门店 id 分库分表，水平拆分到 101 个库里，表变为逻辑表，单表 18w 数据

• 資深大佬 : wqhui

  分表呗，读频繁的话就做主从读写分离或者用缓存

• 資深大佬 : opengps

  表分区，分表，分库，集群
  就这么个优化路线

• 資深大佬 : sagaxu

  才 2000 万就慢，分表没用

• 資深大佬 : CStarter

  @peyppicp 101 个库？

• 資深大佬 : vinsa

  才 2KW 数据怕啥，分个区就好了，还能上个 10 倍，主键查询瞬回。

• 資深大佬 : sonxzjw

  简单，分表分库

• 資深大佬 : yc8332

  这种东西存下来后面不都是走缓存的吗

• 資深大佬 : pmispig

  上 ssd,上好的 ssd,换 cpu 换主频高的 cpu

• 資深大佬 : fareware

  2kw 慢不是硬件或者设计问题吗？

• 資深大佬 : mymike

  根本没必要分库分表 ES，硬件性能与配置可能需要调整下，其实单机上亿没有丝毫问题

• 主 資深大佬 : fengya68

  @zoharSoul 有道理 现在表结构是 MyIsam 有必要转 InnoDb 吗

• 主 資深大佬 : fengya68

  @mymike 商城类就怕延迟高,现在有时候就会卡一下 看来优化还有很长的一段路

• 資深大佬 : zoharSoul

  @fengya68
  看你查询逻辑了.
  一般来说可以转

• 資深大佬 : zoharSoul

  @cominghome 字段比较少就 10 多个吧.
  合理的索引 + 相对简单的查询..
  现在 mysql 的性能超乎你的想象…

  别听那些讲面试的瞎几把扯淡,几百万就分库分表很多时候是纯粹给自己加戏.

• 資深大佬 : encro

  所有的 mysql 慢问题的三个常规操作：
  1，慢日志；
  2，慢日志分析工具；
  3，explain ；

• 資深大佬 : kiddult

  @fengya68 卡一下多半和 mysql 没啥关系，查一下慢日志，100%有人查询没走索引瞎操作了

• 資深大佬 : xuanbg

  难道每个门店都是专有的商品？看着也不像啊，1700 门店才 8000 种。应该是大部分商品所有门店都有，小部分商品某些门店专有吧？

  如果这样的话，可以给权限分级别啊。譬如分为：公共、分组、门店这么几个级别。公共的就是所有门店都能访问；分组的就是要有组权限的才能访问，组权限就是给门店分组，按分组授权；门店的就是指定门店才能访问，和你现在的做法一个样。这样你的权限关系表就能缩减几百倍的数据。我估计有个几万行就足够了。
• 資深大佬 : leonidas

  常规操作索引优化 长远考虑还是的话水平拆分吧

• 資深大佬 : encro

  @xuanbg

  分权不如直接店铺对商品快。因为还有排序等附加信息吧。

  这里面其实是主表要做好，主表只能是关联表。。

  select p.name from shop_product sp, product p where sp.shop_id=xxx and sp.product_id=p.id limit 100;

  如果 sp 的 shop_id 建立了索引，那么几千万数据，还是毫秒级的。

  什么？还在用 MyIsam ？难道非常享受断电之后 repair 的过程？

• 資深大佬 : encro

  @zoharSoul

  阿里云上数据库，最低配置一年 2 千那种，最大的表存着 2 亿，感觉还可以拼一拼。

• 資深大佬 : Michaelssss

  单表也就 2GB 左右大小把。。都 0202 年了，MySQL 已经不是你想的那种弱鸡了

• 資深大佬 : realpg

  垃圾服务器，单表 4200 万无性能压力啊
  还是执行有问题

• 資深大佬 : realpg

  @cominghome #2
  查询都简单化，很容易 handle
  你天天全是复杂到吓死人的查询，恨不得八个表 full join 那肯定不行

  主要还是表结构 查询设计

• 資深大佬 : gemini767

  @zoharSoul 百万数据分库分表确实加戏，但是上亿数据单表查询也是牛了。。个人经验千万数据业务稍微复杂，rt 抖动的就非常大了，生产风险很大。

• 資深大佬 : ylsc633

  2kw 就瓶颈了……

  肯定是你索引建的不对或者 sql 写的有问题!

• 資深大佬 : collery

  不仅要看行数，还得看数据量大小了

• 資深大佬 : xcstream

  查询方式有问题吧 可以先查 id 再 id 查数据

• 資深大佬 : Evilk

  @Michaelssss 是的,我们最近才升级了 MySQL8.0,而且现在硬件性能已经很好了

• 資深大佬 : Erroad

  2kw 慢不是单表的原因了

• 主 資深大佬 : fengya68

  @xuanbg 每个门店 对应每个商品价格都不同 所以大区 区域 站点 门店 都是一个授权的过程

• 資深大佬 : kiddingU

  1 、分表分库
  2 、优化查询
  3 、查询可以走 ES

• 資深大佬 : gaocheng

  没有什么事情是钱解决不了的，如果还是解决不了就是钱没花到位无论是请人还是买设备买服务

• 資深大佬 : ccnccy

  没索引吧，有的话，应该不会太慢。

• 主 資深大佬 : fengya68

  慢日志高于 0.1 秒的没有,并发一上来 还是会导致卡顿的,还是得好好排查下其他问题

• 主 資深大佬 : fengya68

  @realpg 阿里云通用服务器 8 核 16g cpu 没满过 就是偶然会卡一下 阿里云的服务器还是可以的 慢日志也没有 设置 0.1 秒

• 資深大佬 : shenjixiang

  数据量大了最好优化下 mysql 的默认配置，可以按门店 id 做做表分区

• 資深大佬 : zhuweiyou

  应该是没索引

• 資深大佬 : qbmiller

  @zoharSoul 没毛病，阿里后台可能大数据性质的 MySQL

• 資深大佬 : yukiloh

  去年看到别人评价数据库说两千万是瓶颈
  现在直接两个亿，这么给力的吗…