我们正在运行一个定制的广告服务器解决方案，在某些情况下，我们在MySQL中存储和递增递减计数和汇总值，以进行优化。
我知道在MySQL中保存计数并不理想，尽管我并不100%确定为什么。我的猜测是，在磁盘上的写入速度比在内存中的写入速度要慢，所以将计数保存在Redis中会比保存在MySQL中效果更好。但这将给我们的系统增加几层额外的复杂性，并且意味着在多个组件上的严重变化。
在过去，我们看到连接数堆积如山，CPU利用率也在上升，但在缓存了大部分请求并切换到更快的磁盘后，我们已经成功地将这个限制上移。目前我们每天处理的请求量在1000-2000万，采用的是主从MySQL的配置，其中写是发给主服务器的，而大部分读是由从服务器完成的。另外，再增加一个从属服务器也完全不是问题。
我担心的是主服务器上的写入，虽然它们只是在5张表中各增加一行的微小操作。
所以我的问题是：根据你的经验，我可以期望在MySQL中每秒安全地执行多少次这样的小写操作才会达到极限？我听说有人同时处理10万个连接，但如果这些连接都试图在同一秒内增量一行怎么办？在需要的时候，有什么好的策略来扩大这个规模？
谢谢！我们正在运行一个定制的广告服务器。
对于InnoDB，你可能用SSD就可以了。
20M UPDATEs 每天=230second；如果有峰值，则更多。
旋转磁盘（HDD）：每秒100次写入。
固态硬盘（SSD）。 可能1000秒。
批量 INSERTs 运行速度更快。
RAID的某些变体运行速度更快。
带有电池备份写入缓存的RAID控制器运行速度非常快（直到缓存饱和）。
对于保持 "喜欢 "或 "浏览量 "或 "点击量 "来说，它是 可能 最好将计数器与其他关于页面产品什么的列分开放在一个表中。 这样一来，更新计数器和处理其他数据的干扰就少了。
有几个设置可以考虑调整。
innodb_flush_log_at_trx_commit = 2 (权衡速度而不是安全)
sync_binlog = OFF
将多个动作合并为一个动作 BEGIN..COMMIT 事务。 但要谨慎对待死锁等问题。
也许你说的不是100K 连接? 这是一个巨大的数字。 超过几十个正在运行的线程（不考虑睡眠线程的数量）是相当多的。
另一种计算点击的方法是不实时记录，而是每隔一小时从Web服务器上刮取一次日志。 有一个单独的进程来计算这一小时（或每5分钟或其他什么）的所有点击，并将其转化为一个单一的数字，以馈送给一个 UPDATE. 这对于一个单独的服务器来说，工作会比较多，但是对于数据库来说，工作量非常小。
如果你坚持使用MySql，那么我建议你使用In Memory Tables。
CREATE TABLE TableName (Column1 INT) ENGINE = MEMORY;
另外
那么我的问题是：根据你的经验，在MySQL中，每秒能安全地进行多少次这样的小写才会达到极限？
我想这里没有人能给你明确的答案。