加`是为了使用mysql的保留字和关键字。比如要创建表select，但是select是关键字，系统不会让你创建，但加上`你就可以创建了，当然用的时候也要加上`的。
2、设计表，选中表，反键设计表；
3、选中某个字段，下面对应一栏Comment，在此添加你的备注即可。 非常方便，修改也很简单。
可以通过update方法进行批量修改，之后添加必要的条件，针对固定条件的数据进行批量修 改。
sql：update table_name SET age=age+1 where id like '%1111% '; 以上语句就是将id字段中包含1111的age字段，进行加1操作。 备注：如果是全部更新的话，去掉后面的where语句即可。 sql：update table_name SET age=25;
当磁盘空间写满了之后，MySQL是无法再写入任何数据的，包括对表数据的写入，以及binlog、binlog-index等文件。
当然了，因为InnoDB是可以把脏数据先放在内存里，所以不会立刻表现出来无法写入，除非开启了binlog，写入请求才会被阻塞。
当MySQL检测到磁盘空间满了，它会：
每分钟：检查空间是否得到释放，以便写入新数据。当发现有剩余空间了，就会继续写入数据，一切照旧。
每十分钟：如果还是发现没剩余空间，则会在日志中写入一条记录，报告磁盘空间满(这时候只写入几个字节还是够的)。
那么，当发现磁盘空间满了之后，我们应该怎么处理呢，建议：
提高监控系统检测频率，预防再次发生；
及时删除不用的文件，释放空间；
可能因磁盘满导致某些线程被阻塞，引发其他线程也被阻塞，可把导致阻塞的线程杀掉，其他被阻塞的线程也就能继续工作了。
有个例外的情况是：
当执行 REPAIR TABLE 或者 OPTIMIZE TABLE 操作时，或者执行完 LOAD DATA INFILE 或 ALTER TABLE 之后批量更新索引时，这些操作会创建临时文件，当执行这些操作过程中mysqld发现磁盘空间满了，就会把这个涉及到的表标记为crashed，删掉临时文件(除了 ALTER TABLE 操作，MySQL会放弃正在执行的操作，删除临时文件，释放磁盘空间)。
备注：当执行这些命令过程中mysqld进程被意外被杀掉的话，其所生成临时文件不会自动删除，需要手工删掉才能释放磁盘空间。
数据库迁移MySQL数据库迁移(数据文件直接迁移)在今年10月下旬的时候，公司的服务器需要迁移，其中涉及到了MySQL数据库迁移。查看了一下MySQL数据文件的大小，接近60G的大小(实际数据并没用那么多)。
由于服务器上业务需要，要尽量减少服务器迁移时的损失。所以迁移时间选在了晚上零点开始，而且要尽量减少迁移所用的时间。
在迁移之前有三种方案：数据库直接导出，拷贝文件到新服务器，在新服务器上导入。
使用【MySQL GUI Tools】中的 MySQLMigrationTool。数据文件和库表结构文件直接拷贝到新服务器，挂载到同样配置的MySQL服务下。
我在我的电脑上用虚拟机测试后，选中了占用时间最少的第三种方案。下面是三种方案的对比：
第一种方案的优点:会重建数据文件，减少数据文件的占用空间。
第一种方案的缺点:时间占用长。
(导入导出都需要很长的时间，并且导出后的文件还要经过网络传输，也要占用一定的时间。
)第二种方案的优点：设置完成后传输无人值守第二种方案的缺点：设置繁琐。传输中网络出现异常，不能及时的被发现，并且会一直停留在数据传输的状态不能被停止，如不仔细观察不会被发现异常。 传输相对其他fang时间长。 异常后很难从异常的位置继续传输。
第三种方案的优点：时间占用短，文件可断点传输。操作步骤少。
（绝大部分时间都是在文件的网络传输）
第三种方案的缺点：可能引起未知问题，暂时未发现。下面介绍一下第三种方案d迁移步骤：保证Mysql版本一致，安装配置基本一致（注意：这里的数据文件和库表结构文件都指定在同一目录data下）停止两边的Mysql服务（A服务器--迁移-->B服务器)删除B服务器Mysql的data目录下所有文件拷贝A服务器Mysql的data目录下除了ib_logfile和.err之外的文件到B服务器data下启动B服务器的Mysql服务，检测是否发生异常迁移完成后，服务启动正常，未发现其他异常问题。备注：经测试，源mysql的安装目录及数据文件目录 可以与 目标Mysql的安装目录及数据文件目录 不一致。
此时，只需要拷贝您所需移动的dbname（如上：pa、testdb）及'mysql'和'ibdata1'，即可。