1.查找进程( top查看进程的占用资源情况,可以很明显看出java的那个进程占用的过高cpu)
2. 查找线程( 使用 top -H -p
3.查找java的堆栈信息 (将线程id转换成十六进制)
4.使用jstack查询线程的堆栈信息( jstack
1.未提交读( 事务的最低隔离级别,一个事务可以读到另一个事务未提交的数据。会出现脏读的情况.)
2.已提交读 (在一个事务修改数据过程中,如果事务没有进行提交,其他事务不能读取该数据。会出现不可重复读的现象.
3.可重复读( 事务A在读取数据的过程中,事务B也可以对相同数据进行读取,但是不能进行修改直到事务A事务结束后,才会释放共享锁,这时事务B才可以增加排他锁,对数据进行修改。会出现幻读的现象.)
4.序列化 ( 事务A在读取A表时,增加了表级共享锁,此时事务B也可以读取A表,但是不能进行任何数据的修改,直到事务A事务结束。随后事务B可以增加对A表的表级排他锁,此时事务A不能读取A表中的任何数据,更不能进行修改.)
脏读:事务A修改某个数据,同时,事务B来读取,此时,事务A在进行回滚,此时,事务B读取的是事务A回滚前的数据, 即出现脏读。
不可重复读:事务A读取A数据,事务B也读取A数据并修改了这个A数据,事务A在读取A数据会发现两次读取的不一样。
幻读:事务A修改了表A的所有数据,同时事务B向A表插入一条数据,事务A在读A表,会发现还有一条没有修改的数据,就 像出现了幻觉一样。
不是,sql的书写顺序跟执行顺序不一样的.
SELECT →FROM → JOIN → ON → WHERE → GROUP BY → HAVING → ORDER BY→ LIMIT
FROM → JOIN → ON → WHERE → GROUP BY → HAVING → SELECT → ORDER BY→ LIMIT
MyISAM(5.5 版本前默认引擎)
InnoDB (5.5 版本后默认引擎)
作用:
1. MyISAM更适合读密集的表,而InnoDB更适合写密集的的表。 在数据库做主从分离的情况下,经常选择MyISAM作为主库的存储引擎。
2. 如果需要事务支持,并且有较高的并发读取频率(MyISAM的表锁的粒度太大,所以当该表写并发量较高时,要等待的查询就会很多了),这时选InnoDB是不错的。如果你的数据量很大(MyISAM支持压缩特性可以减少磁盘的空间占用),而且不需要支持事务时,MyISAM是最好的选择。
1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。
2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描.
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.应尽量避免在 where 子句中对字段进行表达式操作,这将导致引擎放弃使用索引而进行全表扫描。
如:
select id from t where num/2=100
应改为:
select id from t where num=100*2
7.应尽量避免在where子句中对字段进行函数操作,这将导致引擎放弃使用索引而进行全表扫描。
如:
select id from t where substring(name,1,3)='abc'--name以abc开头的id
应改为:
select id from t where name like 'abc%'
8.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算,否则系统将可能无法正确使用索引。
9.在使用索引字段作为条件时,如果该索引是复合索引,那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引,否则该索引将不会被使用,并且应尽可能的让字段顺序与索引顺序相一致。
10.任何地方都不要使用 select * from t ,用具体的字段列表代替“*”,不要返回用不到的任何字段
未完待续.....