技术博客
C# .NET Core 3.0+ 的 Runtime.ProcessorCount（替代旧版 Environment.ProcessorCount）在容器中运行时，**会读取 Linux cgroups 的 CPU 配额**，而不是宿主机物理核数。这和现代 Java JVM 的行为逻辑一致——但前提是你的 .NET 运行时版本够新、且没被手动覆盖。
JavaScript 的正则引擎是回溯型（NFA），不支持自动优化如“自动编译为 DFA”或“自动跳过无效分支”。每次调用 test()、exec()、match() 等方法时，引擎从左到右逐字符尝试匹配，并在遇到失败时回退（backtrack）——这是性能瓶颈的主要来源。
垂直扩展是提升 MySQL 性能最直接的方式之一，核心思路是通过增强单台服务器的硬件能力（CPU、内存、磁盘、网络）来承载更高负载。它不改变架构，实施快、运维简单，适合中等规模业务或短期性能瓶颈场景。
多活架构指多个数据中心（或集群）同时对外提供服务，任意一个节点故障时，其余节点能无缝承接流量，不依赖主从切换。它不是简单的负载均衡，而是数据、应用、网络层面协同实现的“真并发、真容灾”。
并发写入卡顿，80% 不是磁盘或 CPU 瓶颈，而是 INSERT 被隐式锁住：InnoDB 默认走行级锁，但若没走索引、或插入间隙（gap lock）、或事务未及时提交，就会触发锁等待甚至死锁。尤其批量插入时，每条 INSERT 单独提交，等于反复加锁/刷日志/刷脏页。
事务不是万能的，滥用反而拖慢 MySQL 性能、增加锁冲突、消耗更多资源。核心问题在于：事务的本质是保证 ACID，而实现一致性与持久性需要额外开销——尤其是锁、日志写入和回滚段管理。
MySQL 接收到 SQL 后，先做词法/语法解析，再进入优化器生成执行计划。这个阶段不涉及磁盘 I/O，但 CPU 消耗明显——特别是当 JOIN 表超过 5 张、或存在多层嵌套 IN/EXISTS 子查询时，优化器可能尝试数百种连接顺序，导致 query_cost 计算膨胀。
Gunicorn是为Python Web应用（如Flask、Django）设计的生产级WSGI HTTP服务器，它通过预加载、多进程和异步worker模型提升并发处理能力。不建议直接用开发服务器（如Flask的run()或Django的runserver）对外提供服务——它们未针对高负载、安全性和稳定性做优化。
MySQL 通过 ACID 特性 和底层机制协同保障事务一致性，核心在于原子性、隔离性与持久性的严格实现，而非仅靠单一功能。
Python 的协程调度核心是 asyncio 事件循环（Event Loop），它不依赖操作系统线程，而是在单线程内通过“挂起-恢复”机制协同调度多个异步任务。理解其模型的关键在于：**事件循环驱动、协程对象需显式 await、I/O 操作自动让出控制权**。