这个是属于系统遗留问题,也就是一种系统的保护机制。就是为了避免出现这种在线修改系统的操作。
创新互联专业为企业提供肃北网站建设、肃北做网站、肃北网站设计、肃北网站制作等企业网站建设、网页设计与制作、肃北企业网站模板建站服务,十年肃北做网站经验,不只是建网站,更提供有价值的思路和整体网络服务。
增加字段属于系统的修改操作。尽量不要在线操作,因为可能出现。未知的漏洞。一定要。离线。修改完毕,然后经过测试后。认为已经没有问题了。在。次日的凌晨发一个通知。停机维护。这样才能保证系统的正常运转。
如果在前期设置系统的时候就预留了。热升级的空间。这样才能达到在线操作的目的,而且系统的金融群总是一部分先升级。
很多情况下,你需要使用系统里边的工具集。在线修改表格。原理其实非常的简单,新建的和原表的表格结构。要一模一样。对这个表格进行修改,然后把结构变更的日期。插入进去。而且还建议您尽量在业务的低缝隙进行修改。避免发生不可控的未知状况。
使用说明:
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 之间行锁等待,这里只是用于示例,原理都是相同的。
三、产生的原因根据我之前接触到的此类问题,大致可以分为以下几种原因