这个是属于系统遗留问题，也就是一种系统的保护机制。就是为了避免出现这种在线修改系统的操作。
创新互联专业为企业提供肃北网站建设、肃北做网站、肃北网站设计、肃北网站制作等企业网站建设、网页设计与制作、肃北企业网站模板建站服务，十年肃北做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。
增加字段属于系统的修改操作。尽量不要在线操作，因为可能出现。未知的漏洞。一定要。离线。修改完毕，然后经过测试后。认为已经没有问题了。在。次日的凌晨发一个通知。停机维护。这样才能保证系统的正常运转。
如果在前期设置系统的时候就预留了。热升级的空间。这样才能达到在线操作的目的，而且系统的金融群总是一部分先升级。
很多情况下，你需要使用系统里边的工具集。在线修改表格。原理其实非常的简单，新建的和原表的表格结构。要一模一样。对这个表格进行修改，然后把结构变更的日期。插入进去。而且还建议您尽量在业务的低缝隙进行修改。避免发生不可控的未知状况。
使用说明：
1、如果是用 MySQL + Apache，使用的又是 FreeBSD 网络操作系统的话，安装时候你应按注意到FreeBSD的版本问题，在FreeBSD 的 3.0 以下版本来说，MySQL Source 内含的 MIT-pthread 运行是正常的，但在这版本以上，你必须使用 native threads。
2、如果在 COMPILE 过程中出了问题，请先检查你的 gcc版本是否在 2.81 版本以上，gmake 版本是否在3.75以上。
3、如果不是版本的问题，那可能是你的内存不足，请使用configure--with-low-memory 来加入。
4、如果要重新做你的configure，那么你可以键入rm config.cache和make clean来清除记录。
5、把 MySQL 安装在 /usr/local 目录下，这是缺省值，您也可以按照你的需要设定你所安装的目录。
有时候，会很不小心，在业务运行中执行了一条锁表语句。这时候该怎么办？
例如：修改元数据。
SHOW FULL PROCESSLIST 查看一下：
发现修改之后，锁表了。这时候怎么办？ 杀死它 KILL 4623660
然后一切又恢复正常了。
一般对于数据量较大的表，需要修改表结构，或者做一些耗时比较久的锁表操作，建议在晚上（业务闲时）执行。这个时候可以配合使用任务处理一下。
如：修改一个表的字段长度，和添加索引
名词解释：
接着回家睡觉，第二天回来检查结果就好了。
附：添加唯一索引示例
MYSQL存储过程结合任务处理耗时操作
重启mysql服务
执行show processlist，找到state，State状态为Locked即被其他查询锁住。KILL 10866。
对于写锁定如下：
1）、如果表没有加锁，那么对其加写锁定。
2）、否则，那么把请求放入写锁队列中。
对于读锁定如下：
1）、如果表没有加写锁，那么加一个读锁。
2）、否则，那么把请求放到读锁队列中。
当然我们可以分别用low_priority 以及high_priority在写和读操作上来改变这些行为。
行锁的等待
在介绍如何解决行锁等待问题前，先简单介绍下这类问题产生的原因。产生原因简述：当多个事务同时去操作（增删改）某一行数据的时候，MySQL 为了维护 ACID 特性，就会用锁的形式来防止多个事务同时操作某一行数据，避免数据不一致。只有分配到行锁的事务才有权力操作该数据行，直到该事务结束，才释放行锁，而其他没有分配到行锁的事务就会产生行锁等待。如果等待时间超过了配置值（也就是 innodb_lock_wait_timeout 参数的值，个人习惯配置成 5s，MySQL 官方默认为 50s），则会抛出行锁等待超时错误。
如上图所示，事务 A 与事务 B 同时会去 Insert 一条主键值为 1 的数据，由于事务 A 首先获取了主键值为 1 的行锁，导致事务 B 因无法获取行锁而产生等待，等到事务 A 提交后，事务 B 才获取该行锁，完成提交。这里强调的是行锁的概念，虽然事务 B 重复插入了主键，但是在获取行锁之前，事务一直是处于行锁等待的状态，只有获取行锁后，才会报主键冲突的错误。当然这种 Insert 行锁冲突的问题比较少见，只有在大量并发插入场景下才会出现，项目上真正常见的是 updatedelete 之间行锁等待，这里只是用于示例，原理都是相同的。
三、产生的原因根据我之前接触到的此类问题，大致可以分为以下几种原因
