关于一次优化

还是炸了，果然一个功能，如果要改到基本看不出原来的样子，最好的方案还是重做，轻装前行。

• 💩山是怎么练成的
• 另外的发现
• 🔚

如果要过要改一个功能，新的设计完全和原来大相迳庭，如果是你，你怎么选择：

1. 改！
2. 重做

考虑到时间就是成本，最后大家选择了在原来的基础上修改。既然大家选择了这么走，先试试吧。

💩山是怎么练成的

任务分好了，用户模块。让我看看当时别人怎么写的，看了一天。。。。。，（山西粗口），总结出如下问题：

1. 用户表字段太多，平时能用到的，用不到的，全在里面。
2. 索引没改，好多查询都覆盖不到了。
3. 一个SELECT 一个缓存，这么大字段，倒是拆一下啊。。。

好了好了，找到问题就可以下手了，好在单测还是有的，能省点儿事儿。目前看下来，

1. 大部分业务只用在用户这块只用ID，UID，name，descrpition，status这几个字段，为了减少更新所需要的时间，先把他们拆下来，缓存也可以跟着拆一下。
2. 目前30w这个量，加上缓存压力不大，先不考虑分库。
3. 优化SQL
4. 重建索引

另外的发现

SELECT id,name FROM users OFFSET 200000 LIMIT 10,请问这个SQL有问题么？我当时觉得没问题，后来是有的：

• 这样会导致扫描的行数过多，SQL会很慢。
  怎么解决：
  目前是自己缓存当前page的最后一个用户ID,用于下一个page的查询，SQL改为:
  SELECT id,name FROM users WHERE id > N OFFSET 200000 LIMIT 10

🔚

好了好了，搞完了，常回来看看，上述问题，以后注意，自己别犯。