mysqldump 不就行了么？ 数据库显然不是拷贝数据文件来备份的……

所以嘛 不同的场景用不同的机制

没用 Backup 吗……

原来 postgresql 就是这样被你们用 MySQL 打败的

#1 楼 @kgen #3 楼 @_samqiu 都不如直接拷贝文件来得快

#5 楼 @gaicitadie 快慢比较首先要建立在正确性的前提下，你这么搞，数据根本是错的，没有一致性，没有 flush buffer。

要是不考虑正确性，随机生成 0101 数据还更快呢。

#6 楼 @kgen 一般网站不需要考虑一致性，丢些数据也是可以容忍的，落伍者论坛，帖子 7000 万，会员 100 万，myisam，也是用脚本每天凌晨关站备份，等备份好了自动开站，估计数据库得有几十上百 G，没猜错的话应该是备份文件的

哪个大大知道怎么把 innodb 转成 myisam？我想把数据库转成 myisam 的，当时开发的时候没考虑到这个问题，就用了默认的 innodb

#8 楼 @gaicitadie

alter table table_name engine=myisam;

#9 楼 @messiahxu 谢谢，不会清空以前的数据吧

#10 楼 @gaicitadie 你最好还是备份下，虽然我之前是没出问题

#7 楼 @gaicitadie 呵呵，你一定要丢点数据才舒服的话，我也没什么好说的了。

myisam 容易表损坏，尤其是频繁读写的类型……

我是自动 mylvmbackup 然后 rsync 到树莓派上

支持 @kgen 在此帖中的观点

#6 楼 @kgen 我一直是用 Bash 停 mysql 再 copy myisam 表，这样就不会有数据一致性问题吧。

如果不停 Mysql，先 LOCK TABLES，再 FLUSH TABLES，然后再 copy 应该也 OK 吧。

因为数据太大，mysqldump 太不实用了。

#16 楼 @Peter 嗯，你停了 MySQL 再复制就没问题了。不过这样就要停服务，从可用性角度来说，体验会不太好。LOCK TABLES + FLUSH TABLES 也一样会导致那段时间不能写入。

如果数据太大，mysqldump 时间太久，可以考虑用 Master/Slave 方式，然后从 Slave 上备份，对 Master 性能无影响，又保证数据一致性。

#17 楼 @kgen 这么快回复，先说句新年好。

我都凌晨 3 点在 Slave 备份，除了你这样的用户没睡，其他的都应该在做梦了，影响不了的，呵呵

innodb 热备方案很成熟了，你不熟悉又不肯花时间去研究 myisam 有 myisam 的问题，你到时候也是不花时间上来抱怨一声，下面你打算换什么？

#19 楼 @leopku //nod

顶一下 #17 楼 @kgen

从 Slave 上面拉啊，停机这事儿是谁想出来的。这怎么能接受啊...

#19 楼 @leopku innodb 的小站继续 innodb，免得转 myisam 出什么岔子，好在数据量不大，用 mysqldump 也很快。另一个数据量大的继续 myisam，总之能不折腾就不折腾。个人站长的路子很辛苦，经常会因为各种原因一个人在网上带着数据到处打游击，部署方案能简则简，每天凌晨暂停几分钟基本没有什么影响

搭车问一下 will_paginate 对 InnoDB 的 select count 是怎么优化的

#23 楼 @gaicitadie 数据量不大的时候优化啥呀？