单表千万级, 要根据各种查询得到 ID 集合; 已经建立了各种索引, 速度还是慢

• 資深大佬 : hooopo

  用 postgres 有布隆索引

• 資深大佬 : shaoyijiong

  要不上 es

• 主 資深大佬 : RickyC

  @hooopo
  @shaoyijiong

  我们只要求查询总数小于 10 万的 id 集合;
  现在可以得到各种查询的总数

  这也必须改成其他数据库或者上 es 吗?

  es 可以在 PHP 用?

• 資深大佬 : aimaodeyuer

  @RickyC es 完美适配

• 資深大佬 : nomansky

  binlog 订阅同步到 es，在 es 里面做查询

• 資深大佬 : fareware

  如果是 MySQL , 很多时候，建了很多索引恰恰是选错的索引的原因。
  可选出几个慢查询，explain 是否真正使用了你想让 MySQL 使用的最佳索引。
  如果的确使用了期望索引，还很慢，可能是索引区分度过低，业务是否可调整？保证大部分查询可以用到良好的索引。
  如果业务无法调整，对于 1k 余种查询组合，宽表还是多表 join ？宽表是否可拆分，多表 join 是否可优化。
  如果使用缓存，读多写少，还是读少写多？前者如何保证缓存高可用？后者不适合使用缓存。是否有冷热数据？
  如果使用 ES，如何保证一致性，如何处理深度分页….
  我一直觉得，做技术和做事，都要循序渐进，新技术名词不是撑门面的，合适地方用合适东西，保证可演进。
  单一句“用 Es”, 那不如直接一步到位，搜搜最牛掰的搜索架构得了。

• 資深大佬 : encro

  同意上，先 explain 语句看看吧。
  Why slow ？毕竟 mysql 的专家们并不比 es 专家傻。。。
  瓶颈究竟在磁盘还是内存还是 CPU ？

  连单机 SQL 都用不好去用分布式的 ES?

• 資深大佬 : encro

  我在阿里云 rds 一个 1h1g 的数据库，已经妥妥跑了近亿数据，平均时间不超过 0.2s 。

• 資深大佬 : wangyzj

  理论上千万数据，优化好查询，不应该出问题才对
  结构化查询我觉得上 es 有点过了

• 資深大佬 : daxin945

  如果业务中聚合使用的比较多的话 可以尝试下 ClickHouse

• 資深大佬 : ylsc633

  千万数据 只要命中索引 肯定没有任何性能问题

  建议 explain 看一下 然后优化一下 sql 语句

  我好几个亿的表查询都没有这么慢

• 主 資深大佬 : RickyC

  @ylsc633
  @daxin945
  @wangyzj
  @encro
  @encro
  @fareware

  千万数据命中索引就没有任何问题吗?
  分页的情况, 速度还可以.

  但是这是从全表取出符合条件的所有 ID,
  每次得到的 ID 表数据量可能在 4-5 万;
  也能做到 1 秒以内吗?

• 資深大佬 : Rekkles

  刚刚测试 mysql5.7 单表 11G 1400w+条 查询 5w 条 id 耗时 43ms

• 主 資深大佬 : RickyC

  @Rekkles 我去, 厉害了 电脑啥配置

• 資深大佬 : inwar

  @Rekkles 老哥数据集哪里找的

• 資深大佬 : fangcan

  @Rekkles 服务器什么配置？

• 資深大佬 : Rekkles

  @RickyC #14
  8C32G

  @inwar #15
  自己公司的库啊

  @fangcan #16
  8C32G