SQLite作为一款小型的嵌入式数据库，本身没有提供复杂的锁定机制，无法内部管理多路并发下的数据操作同步问题，更谈不上优化，所以涉及到多路并发的情况，需要外部进行读写锁控制，否则SQLite会返回SQLITE_BUSY错误，以驳回相关请求。
返回SQLITE_BUSY主要有以下几种情况：
1。当有写操作时，其他读操作会被驳回
2。当有写操作时，其他写操作会被驳回
3。当开启事务时，在提交事务之前，其他写操作会被驳回
4。当开启事务时，在提交事务之前，其他事务请求会被驳回
5。当有读操作时，其他写操作会被驳回
6。读操作之间能够并发执行
基于以上讨论，可以看出这是一个典型的读者写者问题，读操作要能够共享，写操作要互斥，读写之间也要互斥
可以设计如下的方案解决并发操作数据库被锁定的问题，同时保证读操作能够保持最大并发
1。采用互斥锁控制数据库写操作
2。只有拥有互斥锁的线程才能够操作数据库
3。写操作必须独立拥有互斥锁
4。读操作必须能够共享互斥锁，即在第一次读取的时候获取互斥锁，最后一次读取的时候释放互斥锁
❷ spring boot动态修改es的连接地址
在项目启动后，使用修改配置文件+restart（）连接/连接池对象的方法解决。
使用读写锁，给restart（）、setUrl（）等代码块加写锁，给数据库操作方法加读锁。这样就可以在修改数据库连接信息时，先获取写锁，保证数据库操作方法不能执行。而在不修改连接时，数据库操作方法之间获取的是读锁，不会影响线程彼此之间的操作。
❸ Mysql到底是怎么实现MVCC的
Mysql到底是怎么实现MVCC的
Mysql到底是怎么实现MVCC的？这个问题无数人都在问，但google中并无答案，本文尝试从Mysql源码中寻找答案。
在Mysql中MVCC是在Innodb存储引擎中得到支持的，Innodb为每行记录都实现了三个隐藏字段：
6字节的事务ID（DB_TRX_ID ）
7字节的回滚指针（DB_ROLL_PTR）
隐藏的ID
6字节的事物ID用来标识该行所述的事务，7字节的回滚指针需要了解下Innodb的事务模型。
1. Innodb的事务相关概念
为了支持事务，Innbodb引入了下面几个概念：
redo log
redo log就是保存执行的SQL语句到一个指定的Log文件，当Mysql执行recovery时重新执行redo log记录的SQL操作即可。当客户端执行每条SQL（更新语句）时，redo log会被首先写入log buffer；当客户端执行COMMIT命令时，log buffer中的内容会被视情况刷新到磁盘。redo log在磁盘上作为一个独立的文件存在，即Innodb的log文件。
undo log
与redo log相反，undo log是为回滚而用，具体内容就是事务前的数据库内容（行）到undo buffer，在适合的时间把undo buffer中的内容刷新到磁盘。undo buffer与redo buffer一样，也是环形缓冲，但当缓冲满的时候，undo buffer中的内容会也会被刷新到磁盘；与redo log不同的是，磁盘上不存在单独的undo log文件，所有的undo log均存放在主ibd数据文件中（表空间），即使客户端设置了每表一个数据文件也是如此。
rollback segment
回滚段这个概念来自Oracle的事物模型，在Innodb中，undo log被划分为多个段，具体某行的undo log就保存在某个段中，称为回滚段。可以认为undo log和回滚段是同一意思。
锁
Innodb提供了基于行的锁，如果行的数量非常大，则在高并发下锁的数量也可能会比较大，据Innodb文档说，Innodb对锁进行了空间有效优化，即使并发量高也不会导致内存耗尽。
对行的锁有分两种：排他锁、共享锁。共享锁针对对，排他锁针对写，完全等同读写锁的概念。如果某个事务在更新某行（排他锁），则其他事物无论是读还是写本行都必须等待；如果某个事物读某行（共享锁），则其他读的事物无需等待，而写事物则需等待。通过共享锁，保证了多读之间的无等待性，但是锁的应用又依赖Mysql的事务隔离级别。
隔离级别
隔离级别用来限制事务直接的交互程度，目前有几个工业标准：
- READ_UNCOMMITTED：脏读
- READ_COMMITTED：读提交
- REPEATABLE_READ：重复读
- SERIALIZABLE：串行化
Innodb对四种类型都支持，脏读和串行化应用场景不多，读提交、重复读用的比较广泛，后面会介绍其实现方式。
2. 行的更新过程
下面演示下事务对某行记录的更新过程：
1. 初始数据行
F1～F6是某行列的名字，1～6是其对应的数据。后面三个隐含字段分别对应该行的事务号和回滚指针，假如这条数据是刚INSERT的，可以认为ID为1，其他两个字段为空。
2.事务1更改该行的各字段的值
当事务1更改该行的值时，会进行如下操作：
用排他锁锁定该行
❹ 我的程序，查询数据库很慢。请问怎么提高查询速度
SQL提高查询效率
1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num is null
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
select id from t where num=0
3.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。
4.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num=10 or num=20
可以这样查询：
select id from t where num=10
union all
select id from t where num=20
5.in 和 not in 也要慎用，否则会导致全表扫描，如：
select id from t where num in(1,2,3)
对于连续的数值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
6.下面的查询也将导致全表扫描：
select id from t where name like '%abc%'
若要提高效率，可以考虑全文检索。
7.如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：
select id from t where num=@num
可以改为强制查询使用索引：
select id from t with(index(索引名)) where num=@num
8.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where num/2=100
应改为:
select id from t where num=100*2
9.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where substring(name,1,3)='abc'--name以abc开头的id
select id from t where datediff(day,createdate,'2005-11-30')=0--‘2005-11-30’生成的id
应改为:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'
10.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
11.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
12.不要写一些没有意义的查询，如需要生成一个空表结构：
select col1,col2 into #t from t where 1=0
这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样：
create table #t(...)
13.很多时候用 exists 代替 in 是一个好的选择：
select num from a where num in(select num from b)
用下面的语句替换：
select num from a where exists(select 1 from b where num=a.num)
14.并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。
15.索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。
16.应尽可能的避免更新 clustered 索引数据列，因为 clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列，那么需要考虑是否应将该索引建为 clustered 索引。
17.尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
18.尽可能的使用 varchar/nvarchar 代替 char/nchar ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。
19.任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段。
20.尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。
21.避免频繁创建和删除临时表，以减少系统表资源的消耗。
22.临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。
23.在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。
24.如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。
25.尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。
26.使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。
27.与临时表一样，游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许，基于游标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。
28.在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。
29.尽量避免大事务操作，提高系统并发能力。
30.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理
1、避免将字段设为“允许为空”
2、数据表设计要规范
3、深入分析数据操作所要对数据库进行的操作
4、尽量不要使用临时表
5、多多使用事务
6、尽量不要使用游标
7、避免死锁
8、要注意读写锁的使用
9、不要打开大的数据集
10、不要使用服务器端游标
11、在程序编码时使用大数据量的数据库
12、不要给“性别”列创建索引
13、注意超时问题
14、不要使用Select *
15、在细节表中插入纪录时，不要在主表执行Select MAX(ID)
16、尽量不要使用TEXT数据类型
17、使用参数查询
18、不要使用Insert导入大批的数据
19、学会分析查询
20、使用参照完整性
21、用INNER JOIN 和LEFT JOIN代替Where
提高SQL查询效率（要点与技巧）：
· 技巧一：
问题类型：ACCESS数据库字段中含有日文片假名或其它不明字符时查询会提示内存溢出。
解决方法：修改查询语句
sql="select * from tablename where column like '%"&word&"%'"
改为
sql="select * from tablename"
rs.filter = " column like '%"&word&"%'"
===========================================================
技巧二：
问题类型：如何用简易的办法实现类似网络的多关键词查询（多关键词用空格或其它符号间隔）。
解决方法：
'//用空格分割查询字符串
ck=split(word," ")
'//得到分割后的数量
sck=UBound(ck)
sql="select * tablename where"
在一个字段中查询
For i = 0 To sck
SQL = SQL & tempJoinWord & "(" & _
"column like '"&ck(i)&"%')"
tempJoinWord = " and "
Next
在二个字段中同时查询
For i = 0 To sck
SQL = SQL & tempJoinWord & "(" & _
"column like '"&ck(i)&"%' or " & _
"column1 like '"&ck(i)&"%')"
tempJoinWord = " and "
Next
===========================================================
技巧三：大大提高查询效率的几种技巧
1. 尽量不要使用 or，使用or会引起全表扫描，将大大降低查询效率。
2. 经过实践验证，charindex()并不比前面加%的like更能提高查询效率，并且charindex()会使索引失去作用（指sqlserver数据库）
3. column like '%"&word&"%' 会使索引不起作用
column like '"&word&"%' 会使索引起作用（去掉前面的%符号）
（指sqlserver数据库）
4. '%"&word&"%' 与'"&word&"%' 在查询时的区别：
比如你的字段内容为 一个容易受伤的女人
'%"&word&"%' ：会通配所有字符串，不论查“受伤”还是查“一个”，都会显示结果。
'"&word&"%' ：只通配前面的字符串，例如查“受伤”是没有结果的，只有查“一个”，才会显示结果。
5. 字段提取要按照“需多少、提多少”的原则，避免“select *”，尽量使用“select 字段1,字段2,字段3........”。实践证明：每少提取一个字段，数据的提取速度就会有相应的提升。提升的速度还要看您舍弃的字段的大小来判断。
6. order by按聚集索引列排序效率最高。一个sqlserver数据表只能建立一个聚集索引，一般默认为ID，也可以改为其它的字段。
7. 为你的表建立适当的索引，建立索引可以使你的查询速度提高几十几百倍。（指sqlserver数据库）
· 以下是建立索引与不建立索引的一个查询效率分析：
Sqlserver索引与查询效率分析。
表 News
字段
Id：自动编号
Title：文章标题
Author：作者
Content：内容
Star：优先级
Addtime：时间
记录：100万条
测试机器：P4 2.8/1G内存/IDE硬盘
=======================================================
方案1：
主键Id，默认为聚集索引，不建立其它非聚集索引
select * from News where Title like '%"&word&"%' or Author like '%"&word&"%' order by Id desc
从字段Title和Author中模糊检索，按Id排序
查询时间：50秒
=======================================================
方案2：
主键Id，默认为聚集索引
在Title、Author、Star上建立非聚集索引
select * from News where Title like '"&word&"%' or Author like '"&word&"%' order by Id desc
从字段Title和Author中模糊检索，按Id排序
查询时间：2 - 2.5秒
=======================================================
方案3：
主键Id，默认为聚集索引
在Title、Author、Star上建立非聚集索引
select * from News where Title like '"&word&"%' or Author like '"&word&"%' order by Star desc
从字段Title和Author中模糊检索，按Star排序
查询时间：2 秒
=======================================================
方案4：
主键Id，默认为聚集索引
在Title、Author、Star上建立非聚集索引
select * from News where Title like '"&word&"%' or Author like '"&word&"%'
从字段Title和Author中模糊检索，不排序
查询时间：1.8 - 2 秒
=======================================================
方案5：
主键Id，默认为聚集索引
在Title、Author、Star上建立非聚集索引
select * from News where Title like '"&word&"%'
或
select * from News where Author like '"&word&"%'
从字段Title 或 Author中检索，不排序
查询时间：1秒
· 如何提高SQL语言的查询效率?
问：请问我如何才能提高SQL语言的查询效率呢？
答：这得从头说起：
由于SQL是面向结果而不是面向过程的查询语言，所以一般支持SQL语言的大型关系型数据库都使用一个基于查询成本的优化器，为即时查询提供一个最佳的执行策略。对于优化器，输入是一条查询语句，输出是一个执行策略。
一条SQL查询语句可以有多种执行策略，优化器将估计出全部执行方法中所需时间最少的所谓成本最低的那一种方法。所有优化都是基于用记所使用的查询语句中的where子句，优化器对where子句中的优化主要用搜索参数(Serach Argument)。
搜索参数的核心思想就是数据库使用表中字段的索引来查询数据，而不必直接查询记录中的数据。
带有 =、<、<=、>、>= 等操作符的条件语句可以直接使用索引，如下列是搜索参数：
emp_id = "10001" 或 salary > 3000 或 a =1 and c = 7
而下列则不是搜索参数：
salary = emp_salary 或 dep_id != 10 或 salary * 12 >= 3000 或 a=1 or c=7
应当尽可能提供一些冗余的搜索参数，使优化器有更多的选择余地。请看以下3种方法：
第一种方法：
select employee.emp_name,department.dep_name from department,employee where (employee.dep_id = department.dep_id) and (department.dep_code="01") and (employee.dep_code="01");
它的搜索分析结果如下：
Estimate 2 I/O operations
Scan department using primary key
for rows where dep_code equals "01"
Estimate getting here 1 times
Scan employee sequentially
Estimate getting here 5 times
第二种方法：
select employee.emp_name,department.dep_name from department,employee where (employee.dep_id = department.dep_id) and (department.dep_code="01");
它的搜索分析结果如下：
Estimate 2 I/O operations
Scan department using primary key
for rows where dep_code equals "01"
Estimate getting here 1 times
Scan employee sequentially
Estimate getting here 5 times
第一种方法与第二种运行效率相同，但第一种方法最好，因为它为优化器提供了更多的选择机会。
第三种方法：
select employee.emp_name,department.dep_name from department,employee where (employee.dep_id = department.dep_id) and (employee.dep_code="01");
这种方法最不好，因为它无法使用索引，也就是无法优化……
使用SQL语句时应注意以下几点：
1、避免使用不兼容的数据类型。例如，Float和Integer，Char和Varchar，Binary和Long Binary不兼容的。数据类型的不兼容可能使优化器无法执行一些本可以进行的优化操作。例如：
select emp_name form employee where salary > 3000;
在此语句中若salary是Float类型的，则优化器很难对其进行优化，因为3000是个整数，我们应在编程时使用3000.0而不要等运行时让DBMS进行转化。
2、尽量不要使用表达式，因它在编绎时是无法得到的，所以SQL只能使用其平均密度来估计将要命中的记录数。
3、避免对搜索参数使用其他的数学操作符。如：
select emp_name from employee where salary * 12 > 3000;
应改为：
select emp_name from employee where salary > 250;
4、避免使用 != 或 <> 等这样的操作符，因为它会使系统无法使用索引，而只能直接搜索表中的数据。
· ORACAL中的应用
一个1600万数据表－－短信上行表TBL_SMS_MO
结构：
CREATE TABLE TBL_SMS_MO
(
SMS_ID NUMBER,
MO_ID VARCHAR2(50),
MOBILE VARCHAR2(11),
SPNUMBER VARCHAR2(20),
MESSAGE VARCHAR2(150),
TRADE_CODE VARCHAR2(20),
LINK_ID VARCHAR2(50),
GATEWAY_ID NUMBER,
GATEWAY_PORT NUMBER,
MO_TIME DATE DEFAULT SYSDATE
);
CREATE INDEX IDX_MO_DATE ON TBL_SMS_MO (MO_TIME)
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE
(
INITIAL 1M
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
);
CREATE INDEX IDX_MO_MOBILE ON TBL_SMS_MO (MOBILE)
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE
(
INITIAL 64K
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
);
问题：从表中查询某时间段内某手机发送的短消息，如下SQL语句：
SELECT MOBILE,MESSAGE,TRADE_CODE,MO_TIME
FROM TBL_SMS_MO
WHERE MOBILE='130XXXXXXXX'
AND MO_TIME BETWEEN TO_DATE('2006-04-01','YYYY-MM-DD HH24:MI:SS') AND TO_DATE('2006-04-07','YYYY-MM-DD HH24:MI:SS')
ORDER BY MO_TIME DESC
返回结果大约需要10分钟，应用于网页查询，简直难以忍受。
分析：
在PL/SQL Developer，点击“Explain Plan”按钮（或F5键），对SQL进行分析，发现缺省使用的索引是IDX_MO_DATE。问题可能出在这里，因为相对于总数量1600万数据来说，都mobile的数据是很少的，如果使用IDX_MO_MOBILE比较容易锁定数据。
如下优化：
SELECT /*+ index(TBL_SMS_MO IDX_MO_MOBILE) */ MOBILE,MESSAGE,TRADE_CODE,MO_TIME
FROM TBL_SMS_MO
WHERE MOBILE='130XXXXXXXX'
AND MO_TIME BETWEEN TO_DATE('2006-04-01','YYYY-MM-DD HH24:MI:SS') AND TO_DATE('2006-04-07','YYYY-MM-DD HH24:MI:SS')
ORDER BY MO_TIME DESC
测试：
按F8运行这个SQL，哇～... ... 2.360s，这就是差别。
http://www.cnblogs.com/ShaYeBlog/archive/2013/07/31/3227244.html
❺ 数据库分区和分表的区别
分区、分表、分库的详细理解
一、什么是分区、分表、分库
分区
就是把一张表的数据分成N个区块，在逻辑上看最终只是一张表，但底层是由N个物理区块组成的
分表
就是把一张表按一定的规则分解成N个具有独立存储空间的实体表。系统读写时需要根据定义好的规则得到对应的字表明，然后操作它。
分库
一旦分表，一个库中的表会越来越多
将整个数据库比作图书馆，一张表就是一本书。当要在一本书中查找某项内容时，如果不分章节，查找的效率将会下降。而同理，在数据库中就是分区。
二、常用的单机数据库的瓶颈
问题描述
单个表数据量越大，读写锁，插入操作重新建立索引效率越低。
单个库数据量太大（一个数据库数据量到就是极限）
单个数据库服务器压力过大
读写速度遇到瓶颈（并发量几百）
三、分区
什么时候考虑使用分区？
一张表的查询速度已经慢到影响使用的时候。
sql经过优化
数据量大
表中的数据是分段的
对数据的操作往往只涉及一部分数据，而不是所有的数据
分区解决的问题
主要可以提升查询效率
分区的实现方式（简单）
mysql5 开始支持分区功能
四、分表
什么时候考虑分表？
一张表的查询速度已经慢到影响使用的时候。
sql经过优化
数据量大
当频繁插入或者联合查询时，速度变慢
分表解决的问题
分表后，单表的并发能力提高了，磁盘I/O性能也提高了，写操作效率提高了
查询一次的时间短了
数据分布在不同的文件，磁盘I/O性能提高
读写锁影响的数据量变小
插入数据库需要重新建立索引的数据减少
分表的实现方式（复杂）
需要业务系统配合迁移升级，工作量较大
分区和分表的区别与联系
分区和分表的目的都是减少数据库的负担，提高表的增删改查效率。
分区只是一张表中的数据的存储位置发生改变，分表是将一张表分成多张表。
当访问量大，且表数据比较大时，两种方式可以互相配合使用。
当访问量不大，但表数据比较多时，可以只进行分区。
常见分区分表的规则策略（类似）
Range（范围）
Hash（哈希）
按照时间拆分
Hash之后按照分表个数取模
在认证库中保存数据库配置，就是建立一个DB，这个DB单独保存user_id到DB的映射关系
❻ mysql中innodb引擎的行锁是通过加在什么上完成
行锁的等待
在介绍如何解决行锁等待问题前，先简单介绍下这类问题产生的原因。产生原因简述：当多个事务同时去操作（增删改）某一行数据的时候，MySQL 为了维护 ACID 特性，就会用锁的形式来防止多个事务同时操作某一行数据，避免数据不一致。只有分配到行锁的事务才有权力操作该数据行，直到该事务结束，才释放行锁，而其他没有分配到行锁的事务就会产生行锁等待。如果等待时间超过了配置值（也就是 innodb_lock_wait_timeout 参数的值，个人习惯配置成 5s，MySQL 官方默认为 50s），则会抛出行锁等待超时错误。
如上图所示，事务 A 与事务 B 同时会去 Insert 一条主键值为 1 的数据，由于事务 A 首先获取了主键值为 1 的行锁，导致事务 B 因无法获取行锁而产生等待，等到事务 A 提交后，事务 B 才获取该行锁，完成提交。这里强调的是行锁的概念，虽然事务 B 重复插入了主键，但是在获取行锁之前，事务一直是处于行锁等待的状态，只有获取行锁后，才会报主键冲突的错误。当然这种 Insert 行锁冲突的问题比较少见，只有在大量并发插入场景下才会出现，项目上真正常见的是 update&delete 之间行锁等待，这里只是用于示例，原理都是相同的。
根据我之前接触到的此类问题，大致可以分为以下几种原因：
1. 程序中非数据库交互操作导致事务挂起将接口调用或者文件操作等这一类非数据库交互操作嵌入在 SQL 事务代码之中，那么整个事务很有可能因此挂起（接口不通等待超时或是上传下载大附件）。
2. 事务中包含性能较差的查询 SQL事务中存在慢查询，导致同一个事务中的其他 DML 无法及时释放占用的行锁，引起行锁等待。
3. 单个事务中包含大量 SQL通常是由于在事务代码中加入 for 循环导致，虽然单个 SQL 运行很快，但是 SQL 数量一大，事务就会很慢。
4. 级联更新 SQL 执行时间较久这类 SQL 容易让人产生错觉，例如：update A set ... where ...in (select B) 这类级联更新，不仅会占用 A 表上的行锁，也会占用 B 表上的行锁，当 SQL 执行较久时，很容易引起 B 表上的行锁等待。
5. 磁盘问题导致的事务挂起极少出现的情形，比如存储突然离线，SQL 执行会卡在内核调用磁盘的步骤上，一直等待，事务无法提交。综上可以看出，如果事务长时间未提交，且事务中包含了 DML 操作，那么就有可能产生行锁等待，引起报错。
❼ java怎样将数据保存到缓存中，之后再保存
Java中可以使用队列来保存数据，当使用的时候，加上锁，防止其他进程访问，当不用的时候保存到数据库里面，示例如下：
packagecom.henry;
importjava.util.HashMap;
importjava.util.Map;
importjava.util.Random;
importjava.util.concurrent.locks.ReadWriteLock;
importjava.util.concurrent.locks.ReentrantReadWriteLock;
publicclassCacheDataTest{
staticMap<Integer,Object>dataMap=newHashMap<Integer,Object>();
staticReadWriteLocklock=newReentrantReadWriteLock();//创建读写锁的实例
staticObjectgetData(Integerkey){
lock.readLock().lock();//读取前先上锁
Objectval=null;
try{
val=dataMap.get(key);
if(val==null){
//
lock.readLock().unlock();
lock.writeLock().lock();
try{
//可能已经由其他线程写入数据
if(val==null){
//dataMap.put(key,"");//queryfromdb
val=queryDataFromDB(key);
}
}finally{
//
lock.readLock().lock();
//Unlockwrite,stillholdread
lock.writeLock().unlock();
}
}
}finally{
lock.readLock().unlock();//最后一定不要忘记释放锁
}
System.out.println("getdatakey="+key+">val="+val);
returnval;
}
staticObjectqueryDataFromDB(Integerkey){
Objectval=newRandom().nextInt(1000);
dataMap.put(key,val);
System.out.println("writeintodatakey="+key+">val="+val);
returnval;
}
publicstaticvoidmain(String[]args){
for(inti=0;i<10;i++){
newThread(newRunnable(){publicvoidrun(){
getData(newRandom().nextInt(5));
}}).start();
}
}
}
❽ 数据库可以区分用户提交数据时候的语句是否核发
数据库可以区分用户提交数据时候的语句会核发
数据库隔离级别，每个级别会引发什么问题，mysql默认是哪个级别
MySQL提供的四种隔离级别，通过设置transaction-isolation值来指定：
串行化：对于同一行记录，写和读都会加锁，当出现读写锁冲突时，会等待。避免脏读，不可重复读和幻读的发生。
可重复读：一个事务执行过程中，在启动时就会创建视图，所以这个事务总和它启动的时候看到的数据是一致的，核心是一致性读，事务更新数据时，只能使用当前读，如果当前记录行锁被占用，就需要进入锁等待。避免脏读，不可重复读的发生。
读已提交：它的视图是在每个sql语句开始执行的时候创建的，所以一个事务提交之后，他的变更才能被其他事务看到。可以避免脏读的发生。
读未提交：没有视图概念，所以一个事务还没提交时，他的变更就能被别的事务看到。任何情况都无法保证。
MySQL默认隔离级别为可重复读。
❾ mysql中的锁都有哪些
MySQL 中有哪些锁？数据库中锁的设计初衷处理并发问题，作为多用户共享资源，当出现并发访问的时候，数据库需要合理控制资源访问规则。锁就是实现这些访问规则中的重要数据。
锁的分类根据加锁范围，MySQL 里面的锁可以分成 全局锁 、 表级锁 、 行锁 三类。
全局锁全局锁，就是对整个数据库实例加锁，MySQL 提供了一个加全局读锁的方法，命令是:
Flush tables with read lock (FTWRL)当需要整个库只读状态的时候，可以使用这个命令，之后其他线程的：数据更新语句（增删改），数据定义语句（建表，修改表结构）和更新事务的提交语句将会被阻塞。
全局锁的使用场景全局锁的定型使用场景，做 全库逻辑备份 。也就是把整个库每个表都 Select 出来，然后存成文本。
如何整个库都只读，会有什么问题？ 如果你在主库上备份，那么在备份期间都不能执行更想，业务就基本上停摆。 如果在从库上备份，那么备份期间从库不能执行主库同步过来的 binlog ,会导致从延迟。 既然要全库只读， 为什么不使用set global readonly=true的方式呢?readonly 方式也可以让全库进入只读状态,但我还是会建议你用FTWRL方式， 主要有两个原因：
一是， 在有些系统中， readonly的值会被用来做其他逻辑，比如用来判断一个库是主库还是备库。因此，修改global变量的方式影响面更大， 我不建议你使用。 二是， 在异常处理机制上有差异。如果执行FTWRL命令之后由于客户端发生异常断开， 那么MySQL会自动释放这个全局锁， 整个库回到可以正常更新的状态。而将整个库设置为readonly之后， 如果客户端发生异常， 则数据库就会一直保持readonly状态， 这样会导致整个库长时间处于不可写状态， 风险较高 表级别锁MySQL 里面表级别的锁有两种：一种是表锁，一种是元数据锁（meta data lok, MDL）。表锁的语法是 ：
lock tables ... read/write与 FTWRL 类似,可以使用 unlock tables 主动释放锁，也可以在客户端断开的时候自动释放。需要注意的是，lock tables语法除了会限制别的线程的读写外，也限定了本线程接下来的操作对象。
MDL 表级锁MDL 不需要显示使用，在访问一个表的时候自动加上， MDL 保证读写的正确性，也就是说在查询数据时，不允许有其他线程对这个表结构做变更。
什么操作会加 MDL 锁？在MySQL 5.5版本中引入了MDL， 当对一个表做增删改查操作的时候，加 MDL读锁 ；当要对表做结构变更操作的时候，加 MDL写锁 。
读锁之间不互斥，因此可以有多个线程同时对一张表增删改查。 读写之间、写锁之间是互斥的，用来保证变更表结构操作的安全性，如果有两个线程要同时给一个表加字段，其中一个要等另外一个执行完才能执行。 更改表结构要注意哪些？给一个表加字段， 或者修改字段， 或者加索引， 需要扫描全表的数据。在对大表操作的时候， 你肯定会特别小心， 以免对线上服务造成影响。而实际上， 即使是小表， 操作不慎也会出问题，导致整个库的线程爆满。
举个例子我们来看一下下面的操作序列， 假设表t是一个小表。
image
session A先启动， 这时候会对表t加一个 MDL读锁 。由于session B需要的也是 MDL读锁 ， 因此可以正常执行。 session C会被blocked， 是因为session A的MDL读锁还没有释放， 而session C需要MDL写锁， 因此只能被阻塞，读写锁互斥。 如果只有session C自己被阻塞还没什么关系， 但是之后所有要在表t上新申请MDL读锁的请求也会被session C阻塞。前面我们说了，所有对表的增删改查操作都需要先申请MDL读锁， 就都被锁住， 等于这个表现在完全不可读写了。如果某个表上的查询语句频繁， 而且客户端有重试机制，也就是说超时后会再起一个新session 再请求的话， 这个 库的线程很快就会爆满 。事务中的MDL锁， 在语句执行开始时申请， 但是语句结束后并不会马上释放， 而会等到整个事务提交后再释放。
怎么解决这个 更改表结构问题比较理想的机制是， 在alter table语句里面设定等待时间， 如果在这个指定的等待时间里面能够拿到MDL写锁最好， 拿不到也不要阻塞后面的业务语句， 先放弃。
ALTER TABLE tbl_name NOWAIT add column ... ALTER TABLE tbl_name WAIT N add column ...