连接是20000，但是活跃会话默认只能有1000个，超过1000活跃根本连不上

oracle 和mysql都有啊，很常见

找个服务器挂机好了，浏览器挂个自动刷新

看一遍101，一个月吧

慢查询是默认300ms以上的sql记录到慢查询日志 sql语句分析是对一段时间执行的sql采样 另外考虑方面不一样，一个看起来很快的sql，比如100ms就能执行出来，但是每秒执行几千次，也可能有性能问题，可以优化到10ms，这种在慢查询就看不到

把相关表analyze分析下，如果还有很多执行计划，那具体看where条件是不是不同，就应该走不同执行计划

理论上应该没啥影响吧

集中式存储你是用fc光纤网络吗，一般来说也没问题，就是存储最好都是ssd，这样速度就够用了

AUTO_ID_CACHE=1当然不会跳号了 不符合设计了。我们就是AUTO_ID_CACHE=1，从来没跳过

执行计划绑定了，如果sql不太多的话

你所在企业是否有出海规划或已开展出海业务？企业出海的核心目标区域 / 国家是哪里？ 没有 驱动企业出海的核心因素是什么（如市场扩张、政策支持等）？ 市场扩展 出海场景下，你最关注数据库的哪些能力（如合规适配、跨区域部署、低运维等）？最关注的技术问题是什么？ 跨区域部署、稳定 出海场景下，你更倾向选择自建数据库还是全托管数据库服务？ 全托管数据库服务 出海业务中，你会选择 TiDB 吗？ 肯定会

一般般，我压测测试快了不到一倍，本来tikv就缓存了小表数据，节约的一点网络开销不会有很大提升

这是sql执行延时，遇到大的sql慢正常，具体看sql语句分析和慢查询

自定义函数 提高大数据量update性能，实测insert into select * from t 读取时候修改，写到临时表，原表删除数据再插回都比直接update快

你要是随机的100个订单号而不是连续的，日志数据分散在多个分区不是正常吗

主键或者联合主键的一部分

这个问题是指sql层面怎么写，还是存储层面设计

可以学，把101 303课程看几遍

sysctl -p