可以考虑仅取 filepath 前面一部分的内容做索引，例如`ADD INDEX xr_top_index(filepath(200), account)`就是仅索引 filepath 前面 200 个字符

订单数据插入后会频繁更新不？不频繁的话可以考虑用 clickhouse

@Nosub #29 ，文章里的 HTTPS 加解密流程图已经过时了，现在的 HTTPS 基本上都是使用 ECDHE 密钥交换协议，服务器的公钥每次都是随机生成的，并不会使用证书里的公钥来加密 AES 密钥

试了一下，确实如上面回答说的，要回表的时候才会使用索引下推，将 SELECT cp_id 改为 SELECT * 就会使用索引下推

我现在在用联想小新 pro 14 ，intel 13500H CPU ，我买的时候是 6k 。除了玩游戏时会明显听到风扇声音，其它日常办公场景都听不到，而且很轻适合外出携带，不过不符合网线口、大小核这两个要求，网线口需要通过扩展坞转接

@Hopetree #17

因为 405 、401 、404 这三个都属于前缀模式匹配。/static/js/css/4.png 同时匹配到了这三个前缀模式，当同时匹配到多个前缀模式时，需要按最长匹配规则进行选取，即最终会命中 405 。

而 405 没有阻止继续匹配正则，所以会继续匹配正则模式，而正则模式就是 402 那个，所以会返回 402

@coderzhangsan #12 ，其实就是匹配相同的子字符串，看哪个子字符串最长

比如有三个 location :
A：/a
B: /a/b
C：/a/b/c

对于字符串 /a/b/c/d ，A 、B 、C 三个都能匹配到，但 C 是最长的，所以最终会采用 C 这个 location

@xlzyxxn #50 ，羡慕啊，5 年就有这么多，我这边很多公司都是按最低工资缴纳公积金的，导致我一个月的公积金只有几百块钱

公积金余额会影响以后公积金贷款的额度，如果你没有公积金贷款买房打算的话可以全部提取出来

@Linken404 #3 ，单纯看配置文件，bbb.example.com 的 http 协议监听端口是 8080 ，你在 return 301 的时候又没有指定 8080 端口，不确定是不是这个原因

我也很喜欢这种真全面屏直边框的外观造型，外观真的无可挑剔！但有几个缺点还在纠结：
1 ）不支持无线充电
2 ）不清楚努比亚的系统好不好用，毕竟是小众厂商，感觉不会像大厂开发的那么好用
3 ）屏幕分辨率不是很高

希望 OP 使用一段时间后，可以再发一下使用感受让我参考下~~

@lesismal @codehz @Evrins 好吧，原来是编译器的问题。感觉多线程并发这块水真的有点深，原子性、内存可见性、指令重排、CPU 的 MESI 缓存一致性协议、内存屏障...涉及到一大堆东西，还要预防编译器的自动优化问题，防止出现预期之外的情况，后面这些再逐块深入研究了，哈哈哈哈...最后再次感谢你们帮忙分析，感谢已经发送~

@dyllen

"根本没有什么可见性的问题，一个协程修改了，另一个协程里面能立马读到新的值"，关于这个我可以给你一段代码例子：
```go
func main() {
flag := true

// 协程 A
go func() {
fmt.Printf("Goroutine start\n")
for flag {
fmt.Printf("Goroutine flag: %v\n", flag)
time.Sleep(time.Second * 1)
continue
}
fmt.Printf("Goroutine finish\n")
}()

for {
flag = false
continue
}
}
```
上面这段代码在我的机器上执行，每次都是不断的输出 "Goroutine flag: true"，说明 main 协程 中的 flag = false 赋值语句没有生效，或者说生效了，但是新的值没有被 协程 A 观测到。

然后还想问下 @codehz 大佬，上面这段代码之所以出现这样的运行结果，是不是也是因为指令重排导致的呢？

感谢所有大佬的热心回复，这个帖子就先讨论到这吧，我要先整理和消化下相关知识，thanks~~

@codehz 并发有三大问题：原子性、有序性、可见性。你说的执行顺序，我觉得是属于有序性的范畴。现在主要是在讨论可见性，而可见性问题是由于 CPU 各个核心缓存不一致 导致的

@BeautifulSoap
@xiaxiaocao
@codehz

首先非常感谢各位大佬的回答，因为我平时高并发做得比较少，所以这块知识有点混乱，再加上表达能力确实不太好，导致挺多人 Get 不到我疑惑的地方。

然后对于 @BeautifulSoap ：
1. 因为单线程程序没有并发可见性问题，所以我就先假设了两个协程分别跑在不同的 CPU 核心上
2. 谢谢你分享的这篇文章，纠正了我的一个误区：之前我以为 happens-before 规则只是一个事件发生顺序的一个规定，但其实它还包含了”可见性“的语义，A happens-before B 代表 A 对共享变量做出的修改，对于 B 来说是可见的。

然后 golang 的 channel 为了满足可见性要求，我猜底层应该会有以下操作：
1. 线程 A 修改共享变量，不能只将修改保存在线程所在 CPU 核心的缓存里，还要将它同步回内存
2. 如果其它 CPU 核心上也有此共享变量，需要将缓存里的变量设置为失效状态
3. 其它核心上的线程读取共享变量，因为所在核心的缓存状态已标记为失效，只能去内存里读，此时就能读到最新的变量值了

我这样理解对不对呢？

@raynor2011
@cyrivlclth

非常感谢，我先消化下你们发出来的链接内容

@ZField #28 对，java 的 volatile 关键字，我看网上资料说是通过禁用 CPU 缓存来解决可见性问题的，但 golang 的 channel 是不是通过同样的方式去解决的就不知道了，还是说可见性问题只存在 java ？但这个貌似也说不通，只要是多线程并发，应该就会有可见性问题

@cyrivlclth #21 所以可见性问题只存在于 Java 语言吗