我正在开发一个高性能的实时应用程序，使用 node.js 和 mysql 作为后端。
为了提高性能，我有一个单独的 node.js 进程更新底层 mysql bd。更新请求排入队列以保证顺序执行（必须）。
我正在考虑在此过程中保持永久打开的数据库连接，以免浪费时间在每次请求时打开它。
其他 DB 请求（更新或读取）直接从 web-server node-js 实例提供，可能是并行的。这些数据库连接当然是在每个请求中创建/释放的。
你觉得这种方法有什么缺点吗？
更新：
重要的附加信息。 我之所以选择这个独立的流程解决方案，主要是因为以下原因……
每次更新前必须执行的逻辑比较复杂，取决于数据库中的数据结构。每次更新之前都需要几个额外的查询。这个独立进程在内存中拥有完整的数据结构，可以非常快速地执行这些检查，并且无需访问数据库（性能提升）。
【问题讨论】：
我看到了缺点。
交易是最大的交易。如果 UPDATE 失败会发生什么？你回滚并重试吗？将消息放回队列中？
我认为更好的方法是在尽可能窄的范围内打开、使用和关闭连接。创建并维护一个连接池，以分摊创建多个事务的成本。
我建议查看 vert.x 而不是 node.js。它是 JVM 的 node.js。它使用非阻塞 I/O 和环形缓冲区事件总线来保证连续、快速的操作。
【讨论】：
你的方法的另一个缺点。
MySQL 因基于超时关闭已打开很长时间的连接而臭名昭著。
Lost connection to MySQL server during query
@duffymo 是正确的：使用池中的短期连接比长期打开的连接更有可能持续工作数百小时。
node.js + mysql connection pooling
我想知道：你说顺序执行是必须的。大型 DBMS（包括大型服务器上的 MySQL）非常擅长处理来自多个连接的并发查询而不会损坏数据。如果您能准确计算出更新顺序的强制要求，您的系统可能会更加健壮。如果您可以在 SQL 本身或可能在某些事务中实现该排序，那么您将拥有一个比坚持只有一个进程进行更新的系统更耐故障。像您提到的那样的单一用途进程在系统测试中不容易调试：它们因各种原因在数百小时后失败而臭名昭著。当它们在生产中出现故障时，每个人都在争先恐后地修复它们，因此没有人有时间对其进行故障排除。
【讨论】：