MyISAM在读操作占主导的情况下是很高效的。可一旦出现大量的读写并发,同InnoDB相比,MyISAM的效率就会直线下降,而 且,MyISAM和InnoDB的数据存储方式也有显著不同:通常,在MyISAM里,新数据会被附加到数据文件的结尾,可如果时常做一些 UPDATE,DELETE操作之后,数据文件就不再是连续的,形象一点来说,就是数据文件里出现了很多洞洞,此时再插入新数据时,按缺省设置会先看这些 洞洞的大小是否可以容纳下新数据,如果可以,则直接把新数据保存到洞洞里,反之,则把新数据保存到数据文件的结尾。之所以这样做是为了减少数据文件的大
小,降低文件碎片的产生。但InnoDB里则不是这样,在InnoDB里,由于主键是cluster的,所以,数据文件始终是按照主键排序的,如果使用自 增ID做主键,则新数据始终是位于数据文件的结尾。
了解了这些基础知识,下面说说MyISAM几个容易忽视的配置选项:
concurrent_insert:
通常来说,在MyISAM里读写操作是串行的,但当对同一个表进行查询和插入操作时,为了降低锁竞争的频率,根据concurrent_insert的设置,MyISAM是可以并行处理查询和插入的:
SET GLOBAL concurrent_insert = 2; 设置,
SHOW GLOBAL VARIABLES LIKE '%concurrent_insert%';查看
当concurrent_insert=0时,不允许并发插入功能。
当concurrent_insert=1时,允许对没有洞洞的表使用并发插入,新数据位于数据文件结尾(缺省)。
当concurrent_insert=2时,不管表有没有洞洞,都允许在数据文件结尾并发插入。
这样看来,把concurrent_insert设置为2是很划算的,至于由此产生的文件碎片,可以定期使用OPTIMIZE TABLE语法优化。
max_write_lock_count:
缺省情况下,写操作的优先级要高于读操作的优先级,即便是先发送的读请求,后发送的写请求,此时也会优先处理写请求,然后再处理读请求。这就造成一 个问题:一旦我发出若干个写请求,就会堵塞所有的读请求,直到写请求全都处理完,才有机会处理读请求。此时可以考虑使用 max_write_lock_count:
max_write_lock_count=1
有了这样的设置,当系统处理一个写操作后,就会暂停写操作,给读操作执行的机会。
low-priority-updates:
我们还可以更干脆点,直接降低写操作的优先级,给读操作更高的优先级。
low-priority-updates=1
综合来看,concurrent_insert=2是绝对推荐的,至于max_write_lock_count=1和low-priority- updates=1,则视情况而定,如果可以降低写操作的优先级,则使用low-priority-updates=1,否则使用 max_write_lock_count=1。
myisam_max_[extra]_sort_file_size足够大
delay_key_write减少io,提高写入性能
bulk_insert_buffer_size
concurrent_insert 设置为2
read_rnd_buffer_size random scan 使用
read_buffer_size 顺序扫描表使用
key cache 的三种方式
key cache 预加载
SET GLOBAL hot_cache.key_buffer_size=16m
SET BLOBAL cold_cache.key_buffer_size=16m
CACHE INDEX example.top_message IN hot_cache
CACHE INDEX example.event IN cold_cache
LOAD INDEX INTO CACHE example.top_message,example.event IGNORE LEAVES
LOAD INDEX INTO CACHE example.user IGNORE LEAVERS,expamle.groups
分享到:
相关推荐
MyISAM在读操作占主导的...可一旦出现大量的读写并发,同InnoDB相比,MyISAM的效率就会直线下降,而 且,MyISAM和InnoDB的数据存储方式也有显著不同:通常,在MyISAM里,新数据会被附加到数据文件的结尾,······
可一旦出现大量的读写并发,同InnoDB相比,MyISAM的效率就会直线下降,而且,MyISAM和 InnoDB的数据存储方式也有显著不同:通常,在MyISAM里,新数据会被附加到数据文件的结尾,可如果时常做一些UPDATE,DELETE操作...
Mysql数据库的优化技术 对mysql优化时一个综合性的技术,主要包括 ...f: 对mysql配置优化 [配置最大并发数my.ini, 调整缓存大小 ] g: mysql服务器硬件升级 h: 定时的去清除不需要的数据,定时进行碎片整理(MyISAM)
对mysql优化时一个综合性的技术,主要包括 a: 表的设计合理化(符合3NF) ...f: 对mysql配置优化 [配置最大并发数my.ini, 调整缓存大小 ] g: mysql服务器硬件升级 h: 定时的去清除不需要的数据,定时进行碎片整理(MyISAM)
即MyISAM同一个表上的读锁和写锁是互斥的,MyISAM并发读写时如果等待队列中既有读请求又有写请求,默认写请求的优先级高,即使读请求先到,所以MyISAM不适合于有大量查询和修改并存的情况,那样查询进程会长时间阻
Mysql优化资料 对mysql优化时一个综合性的技术,主要包括 ...f: 对mysql配置优化 [配置最大并发数my.ini, 调整缓存大小 ] g: mysql服务器硬件升级 h: 定时的去清除不需要的数据,定时进行碎片整理(MyISAM)
通常来说,在MyISAM里读写操作是串行的,但当对同一个表进行查询和插入操作时,为了降低锁竞争的频率,根据concurrent_insert的设置,MyISAM是可以并行处理查询和插入的: 当concurrent_insert=0时,不允许并发插入...
MyISAM存储引擎的特点是:表级锁、不支持事务和全文索引,适合一些CMS内容管理系统作为后台数据库使用,但是使用大并发、重负荷生产系统上,表锁结构的特性就显得力不从心; 以下是MySQL 5.7 MyISAM存储引擎的版本...
f: 对mysql配置优化 [配置最大并发数my.ini, 调整缓存大小 ] g: mysql服务器硬件升级 h: 定时的去清除不需要的数据,定时进行碎片整理(MyISAM) 什么样的表才是符合3NF (范式) 表的范式,是首先符合1NF, 才能满足...
良好的安全连接,自带查询解析、sql语句优化,使用读写锁(细化到行)、事物隔离和多版本并发控制提高并发,完备的事务日志记录,强大的存储引擎提供高效查询(表记录可达百万级),如果是InnoDB,还可在崩溃后进行...
它支持水平扩展(如通过分片、复制等技术)和垂直扩展(如增加硬件资源),以应对大规模数据存储和高并发访问的需求。 安全性与管理工具 MySQL提供了一系列安全措施,如用户账户管理、访问权限控制、SSL/TLS加密...
高性能:MySQL针对性能进行了优化,具有高速读写能力和高并发处理能力。此外,MySQL还支持索引、分区表等机制来提高查询效率。 可扩展性:MySQL可以在单机或者集群环境中运行,并且可以通过主从复制、分片等技术...
1.2.1读写锁4 1.2.2锁粒度4 1.3事务6 1.3.1隔离级别8 1.3.2死锁9 1.3.3事务日志10 1.3.4MySQL中的事务10 1.4多版本并发控制12 1.5MySQL的存储引擎13 1.5.1InnoDB存储引擎16 1.5.2MyISAM存储引擎17 1.5.3...
InnoDB支持事务和行级别锁定,适用于需要高并发读写操作和数据一致性的应用。 MyISAM不支持事务和行级别锁定,适用于读操作较多、写操作较少的应用。 4.什么是主键和外键? 主键是用于唯一标识数据库表中每一条...
innodb 通过多版本并发控制(MVCC)来获得高并发性,并且实现了SQL标准的4种隔离级别,默认为REPEATABLE级别。同时,使用一种被称为next-key locking的策略来避免幻读(phantom)现象的产生。除此之外,InnoDB存储引擎...
MySQL 的存储引擎可能是所有关系型数据库产品中最具有特色的了,不仅可以...读写互相阻塞:不仅会在写入的时候阻塞读取,MyISAM还会在读取的时候阻塞写入,但读本身并不会阻塞另外的读 只会缓存索引:MyISAM可以通过k
采用Redis作菜单缓存,MyBatis读写MySQL数据,业务上包含登录注册、科室管理、医生管理、医生放号、预约挂号、我的挂号、用户留言和新闻资讯功能,模拟了患者从零开始挂号就医的过程。 MySQL 是一款广受欢迎的开源...
本章将对MySQL中两种使用最为频繁的存储引擎MyISAM和Innodb各自的锁定机制进行较为详细的分析。 MySQL锁定机制简介 数据库锁定机制简单来说就是数据库为了保证数据的一致性而使各种共享资源在被并发访问访问变得有序...
# innodb使用后台线程处理数据页上的读写 I/O(输入输出)请求,根据你的 CPU 核数来更改,默认是4 # 注:这两个参数不支持动态改变,需要把该参数加入到my.cnf里,修改完后重启MySQL服务,允许值的范围从 1-64 innodb_...