mysql 截断表与删除
我们将部署一些代码来截断 mysql 4 数据库中的表。我们这样做是为了解决我们在临时表中看到的（并且众所周知的）一些复制“怪异现象”。当我在代码审查中看到这一点时，我的本能反应是“不”，但我在备份它时遇到了困难。
所以，问题是：我是否反应过度？您是否遇到过在 mysql 中使用 truncate table 时遇到的任何我们应该尽量避免的问题？在复制环境中截断怎么样？
We are about to deploy some code that truncates tables in our mysql 4 database. We are doing this to get around some replication 'weirdness' that we are seeing (and is widely known) with temp tables. My knee-jerk reaction when I saw this in a code review was "no", but I'm having trouble backing it up.
So, the question is: am I just overreacting? Have you run into any gotchas using truncate table in mysql that we should try to avoid? How about truncate in a replicated environment?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
截断（至少在 Sybase 中，对于 mySql 不是 100% 确定）
不写入日志。意思是，没有恢复，也没有回滚。
不会自动重建索引统计信息，这意味着优化器在查看给定表时可能无法正常工作。
不会自动重建索引统计信息，
请参阅本文了解 mySQL 的具体详细信息/comparison
这是相关的 mySQL TFM
Truncation (at least in Sybase, not 100% sure about mySql)
Does NOT write to the log. Meaning, no recovery and no rollbacks.
Does not automatically rebuild the index statistics, meaning that the optimizer may not work correctly when looking at a given table.
Please see this article for mySQL specific details/comparison
Here's the relevant mySQL TFM