网站访问量数据库设计
网站访问量大,优化mysql数据库的方法:
1、创建索引
对于查询占主要的应用来说,索引显得尤为重要。很多时候性能问题很简单的就是因为我们忘了添加索引而造成的,或者说没有添加更为有效的索引导致。如果不加索引的话,那么查找任何哪怕只是一条特定的数据都会进行一次全表扫描,如果一张表的数据量很大而符合条件的结果又很少,那么不加索引会引起致命的性能下降。但是也不是什么情况都非得建索引不可,比如性别可能就只有两个值,建索引不仅没什么优势,还会影响到更新速度,这被称为过度索引。
2、复合索引
比如有一条语句是这样的:select * from users where area='beijing' and age=22;
如果我们是在area和age上分别创建单个索引的话,由于mysql查询每次只能使用一个索引,所以虽然这样已经相对不做索引时全表扫描提高了很多效率,但是如果在area、age两列上创建复合索引的话将带来更高的效率。如果我们创建了(area, age, salary)的复合索引,那么其实相当于创建了(area,age,salary)、(area,age)、(area)三个索引,这被称为最佳左前缀特性。因此我们在创建复合索引时应该将最常用作限制条件的列放在最左边,依次递减。
3、索引不会包含有NULL值的列
只要列中包含有NULL值都将不会被包含在索引中,复合索引中只要有一列含有NULL值,那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL。
4、使用短索引
对串行进行索引,如果可能应该指定一个前缀长度。例如,如果有一个CHAR(255)的 列,如果在前10 个或20 个字符内,多数值是惟一的,那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。
5、排序的索引问题
mysql查询只使用一个索引,因此如果where子句中已经使用了索引的话,那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作;尽量不要包含多个列的排序,如果需要最好给这些列创建复合索引。
6、like语句操作
一般情况下不鼓励使用like操作,如果非使用不可,如何使用也是一个问题。like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。
7、不要在列上进行运算
select * from users where YEAR(adddate)<2007;
将在每个行上进行运算,这将导致索引失效而进行全表扫描,因此我们可以改成
select * from users where adddate<‘2007-01-01';
8、不使用NOT IN和<>操作
NOT IN和<>操作都不会使用索引将进行全表扫描。NOT IN可以NOT EXISTS代替,id<>3则可使用id>3 or id<3来代替。
㈡ 如果有一个特别大的访问量,到数据库上,怎么做优化
DB设计:
永远为每张表设置一个ID ,并作为主键
创建索引,必要时用联合索引,并设计索引时避免有默认NULL值的列
DBIO
数据库做读写分离和主从同步,主库负责写入和更新操作,从库负责查询
SQL优化:
不鼓励使用like操作,不要在列上进行运算,不使用NOT IN和<>操,当只要一行数据时使用 LIMIT 1,在Join表的时候使用相当类型的例,并将其索引 ,避免 SELECT * 这种查询方法,用什么数据取什么数据
Java优化:
加缓存
㈢ 大数据量高并发访问数据库结构的设计
大数据量高并发访问数据库结构的设计
如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能。所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的。
在一个系统分析、设计阶段,因为数据量较小,负荷较低。我们往往只注意到功能的实现,而很难注意到性能的薄弱之处,等到系统投入实际运行一段时间后,才发现系统的性能在降低,这时再来考虑提高系统性能则要花费更多的人力物力,而整个系统也不可避免的形成了一个打补丁工程。
所以在考虑整个系统的流程的时候,我们必须要考虑,在高并发大数据量的访问情况下,我们的系统会不会出现极端的情况。(例如:对外统计系统在7月16日出现的数据异常的情况,并发大数据量的的访问造成,数据库的响应时间不能跟上数据刷新的速度造成。具体情况是:在日期临界时(00:00:00),判断数据库中是否有当前日期的记录,没有则插入一条当前日期的记录。在低并发访问的情况下,不会发生问题,但是当日期临界时的访问量相当大的时候,在做这一判断的时候,会出现多次条件成立,则数据库里会被插入多条当前日期的记录,从而造成数据错误。),数据库的模型确定下来之后,我们有必要做一个系统内数据流向图,分析可能出现的瓶颈。
为了保证数据库的一致性和完整性,在逻辑设计的时候往往会设计过多的表间关联,尽可能的降低数据的冗余。(例如用户表的地区,我们可以把地区另外存放到一个地区表中)如果数据冗余低,数据的完整性容易得到保证,提高了数据吞吐速度,保证了数据的完整性,清楚地表达数据元素之间的关系。而对于多表之间的关联查询(尤其是大数据表)时,其性能将会降低,同时也提高了客户端程序的编程难度,因此,物理设计需折衷考虑,根据业务规则,确定对关联表的数据量大小、数据项的访问频度,对此类数据表频繁的关联查询应适当提高数据冗余设计但增加了表间连接查询的操作,也使得程序的变得复杂,为了提高系统的响应时间,合理的数据冗余也是必要的。设计人员在设计阶段应根据系统操作的类型、频度加以均衡考虑。
另外,最好不要用自增属性字段作为主键与子表关联。不便于系统的迁移和数据恢复。对外统计系统映射关系丢失(******************)。
原来的表格必须可以通过由它分离出去的表格重新构建。使用这个规定的好处是,你可以确保不会在分离的表格中引入多余的列,所有你创建的表格结构都与它们的实际需要一样大。应用这条规定是一个好习惯,不过除非你要处理一个非常大型的数据,否则你将不需要用到它。(例如一个通行证系统,我可以将USERID,USERNAME,USERPASSWORD,单独出来作个表,再把USERID作为其他表的外键)
表的设计具体注意的问题:
1、数据行的长度不要超过8020字节,如果超过这个长度的话在物理页中这条数据会占用两行从而造成存储碎片,降低查询效率。
2、能够用数字类型的字段尽量选择数字类型而不用字符串类型的(电话号码),这会降低查询和连接的性能,并会增加存储开销。这是因为引擎在处理查询和连接回逐个比较字符串中每一个字符,而对于数字型而言只需要比较一次就够了。
3、对于不可变字符类型char和可变字符类型varchar都是8000字节,char查询快,但是耗存储空间,varchar查询相对慢一些但是节省存储空间。在设计字段的时候可以灵活选择,例如用户名、密码等长度变化不大的字段可以选择CHAR,对于评论等长度变化大的字段可以选择VARCHAR。
4、字段的长度在最大限度的满足可能的需要的前提下,应该尽可能的设得短一些,这样可以提高查询的效率,而且在建立索引的时候也可以减少资源的消耗。
5、基本表及其字段之间的关系, 应尽量满足第三范式。但是,满足第三范式的数据库设计,往往不是最好的设计。为了提高数据库的运行效率,常常需要降低范式标准:适当增加冗余,达到以空间换时间的目的。
6、若两个实体之间存在多对多的关系,则应消除这种关系。消除的办法是,在两者之间增加第三个实体。这样,原来一个多对多的关系,现在变为两个一对多的关系。要将原来两个实体的属性合理地分配到三个实体中去。这里的第三个实体,实质上是一个较复杂的关系,它对应一张基本表。一般来讲,数据库设计工具不能识别多对多的关系,但能处理多对多的关系。
7、主键PK的取值方法,PK是供程序员使用的表间连接工具,可以是一无物理意义的数字串, 由程序自动加1来实现。也可以是有物理意义的字段名或字段名的组合。不过前者比后者好。当PK是字段名的组合时,建议字段的个数不要太多,多了不但索引占用空间大,而且速度也慢。
8、主键与外键在多表中的重复出现, 不属于数据冗余,这个概念必须清楚,事实上有许多人还不清楚。非键字段的重复出现, 才是数据冗余!而且是一种低级冗余,即重复性的冗余。高级冗余不是字段的重复出现,而是字段的派生出现。
〖例4〗:商品中的“单价、数量、金额”三个字段,“金额”就是由“单价”乘以“数量”派生出来的,它就是冗余,而且是一种高级冗余。冗余的目的是为了提高处理速度。只有低级冗余才会增加数据的不一致性,因为同一数据,可能从不同时间、地点、角色上多次录入。因此,我们提倡高级冗余(派生性冗余),反对低级冗余(重复性冗余)。
9、中间表是存放统计数据的表,它是为数据仓库、输出报表或查询结果而设计的,有时它没有主键与外键(数据仓库除外)。临时表是程序员个人设计的,存放临时记录,为个人所用。基表和中间表由DBA维护,临时表由程序员自己用程序自动维护。
10、防止数据库设计打补丁的方法是“三少原则”
(1) 一个数据库中表的个数越少越好。只有表的个数少了,才能说明系统的E--R图少而精,去掉了重复的多余的实体,形成了对客观世界的高度抽象,进行了系统的数据集成,防止了打补丁式的设计;
(2) 一个表中组合主键的字段个数越少越好。因为主键的作用,一是建主键索引,二是做为子表的外键,所以组合主键的字段个数少了,不仅节省了运行时间,而且节省了索引存储空间;
(3) 一个表中的字段个数越少越好。只有字段的个数少了,才能说明在系统中不存在数据重复,且很少有数据冗余,更重要的是督促读者学会“列变行”,这样就防止了将子表中的字段拉入到主表中去,在主表中留下许多空余的字段。所谓“列变行”,就是将主表中的一部分内容拉出去,另外单独建一个子表。这个方法很简单,有的人就是不习惯、不采纳、不执行。
数据库设计的实用原则是:在数据冗余和处理速度之间找到合适的平衡点。“三少”是一个整体概念,综合观点,不能孤立某一个原则。该原则是相对的,不是绝对的。“三多”原则肯定是错误的。试想:若覆盖系统同样的功能,一百个实体(共一千个属性) 的E--R图,肯定比二百个实体(共二千个属性)的E--R图,要好得多。
提倡“三少”原则,是叫读者学会利用数据库设计技术进行系统的数据集成。数据集成的步骤是将文件系统集成为应用数据库,将应用数据库集成为主题数据库,将主题数据库集成为全局综合数据库。集成的程度越高,数据共享性就越强,信息孤岛现象就越少,整个企业信息系统的全局E—R图中实体的个数、主键的个数、属性的个数就会越少。
提倡“三少”原则的目的,是防止读者利用打补丁技术,不断地对数据库进行增删改,使企业数据库变成了随意设计数据库表的“垃圾堆”,或数据库表的“大杂院”,最后造成数据库中的基本表、代码表、中间表、临时表杂乱无章,不计其数,导致企事业单位的信息系统无法维护而瘫痪。
“三多”原则任何人都可以做到,该原则是“打补丁方法”设计数据库的歪理学说。“三少”原则是少而精的原则,它要求有较高的数据库设计技巧与艺术,不是任何人都能做到的,因为该原则是杜绝用“打补丁方法”设计数据库的理论依据。
11、在给定的系统硬件和系统软件条件下,提高数据库系统的运行效率的办法是:
(1) 在数据库物理设计时,降低范式,增加冗余, 少用触发器, 多用存储过程。
(2) 当计算非常复杂、而且记录条数非常巨大时(例如一千万条),复杂计算要先在数据库外面,以文件系统方式用编程语言计算处理完成之后,最后才入库追加到表中去。
(3) 发现某个表的记录太多,例如超过一千万条,则要对该表进行水平分割。水平分割的做法是,以该表主键PK的某个值为界线,将该表的记录水平分割为两个表。若发现某个表的字段太多,例如超过八十个,则垂直分割该表,将原来的一个表分解为两个表。
(4) 对数据库管理系统DBMS进行系统优化,即优化各种系统参数,如缓冲区个数。
(5) 在使用面向数据的SQL语言进行程序设计时,尽量采取优化算法。
总之,要提高数据库的运行效率,必须从数据库系统级优化、数据库设计级优化、程序实现级优化,这三个层次上同时下功夫。
主键设计:
1、不建议用多个字段做主键,单个表还可以,但是关联关系就会有问题,主键自增是高性能的。
2、一般情况下,如果有两个外键,不建议采用两个外键作为联合住建,另建一个字段作为主键。除非这条记录没有逻辑删除标志,且该表永远只有一条此联合主键的记录。
3、一般而言,一个实体不能既无主键又无外键。在E—R 图中, 处于叶子部位的实体, 可以定义主键,也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。
主键与外键的设计,在全局数据库的设计中,占有重要地位。当全局数据库的设计完成以后,有个美国数据库设计专家说:“键,到处都是键,除了键之外,什么也没有”,这就是他的数据库设计经验之谈,也反映了他对信息系统核心(数据模型)的高度抽象思想。因为:主键是实体的高度抽象,主键与、外键的配对,表示实体之间的连接。
㈣ ASP.net怎么实现网站访问量统计数据得保存到数据库里面
无论你什么程序
其实访问统计不要自己存到数据库
首先对数据库压力很大而且很麻烦
你可以借助第三方统计
比如网络统计都可以
希望能帮助到你
㈤ 如果有一个特别大的访问量,到数据库上,怎么做优化
1、使用缓存技术如redis
2、数据表经常检查,更新,修复
3、优化sql语句,而别是查询语句
4、当只要一行数据时使用 LIMIT 1
5、为搜索字段建立索引,这样查询速度更快
6、在Join表的时候使用相当类型的例,并将其索引
7、避免 SELECT * 这种查询方法,用什么数据取什么数据,这属于sql优化
8、永远为每张表设置一个ID ,并作为主键
9、使用 ENUM 而不是 VARCHAR
10、从 PROCEDURE ANALYSE() 取得建议,PROCEDURE ANALYSE() 会让 MySQL 帮你去分析你的字段和其实际的数据,并会给你一些有用的建议
11、尽可能的使用 NOT NULL
㈥ 网站访问量大 怎样优化mysql数据库
I 硬件配置优化
CPU选择:多核的CPU,主频高的CPU
内存:更大的内存
磁盘选择:更快的转速、RAID、阵列卡,
网络环境选择:尽量部署在局域网、SCI、光缆、千兆网、双网线提供冗余、0.0.0.0多端口绑定监听
II 操作系统级优化
使用64位的操作系统,更好的使用大内存。
设置noatime,nodiratime
[zhangxy@dowload_server1 ~]$ cat /etc/fstab
LABEL=/ / ext3 defaults,noatime,nodiratime 1 1
/dev/sda5 /data xfs defaults,noatime,nodiratime 1 2
优化内核参数
net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_max_syn_backlog=1024
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.neigh.default.gc_thresh3 = 2048
net.ipv4.neigh.default.gc_thresh2 = 1024
net.ipv4.neigh.default.gc_thresh1 = 256
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.default.proxy_arp = 0
net.ipv4.tcp_syncookies = 1
net.core.netdev_max_backlog = 2048
net.core.dev_weight = 64
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_rfc1337 = 1
net.ipv4.tcp_sack = 0
net.ipv4.tcp_fin_timeout = 20
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_max_orphans = 32768
net.core.optmem_max = 20480
net.core.rmem_default = 16777216
net.core.rmem_max = 16777216
net.core.wmem_default = 16777216
net.core.wmem_max = 16777216
net.core.somaxconn = 500
net.ipv4.tcp_orphan_retries = 1
net.ipv4.tcp_max_tw_buckets = 18000
net.ipv4.ip_forward = 0
net.ipv4.conf.default.proxy_arp = 0
net.ipv4.conf.all.rp_filter = 1
kernel.sysrq = 1
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0
net.ipv4.ip_local_port_range = 5000 65000
kernel.shmmax = 167108864
vm.swappiness=0
加大文件描述符限制
Vim /etc/security/limits.conf
加上
* soft nofile 65535
* hard nofile 65535
文件系统选择 xfs
/dev/sda5 /data xfs defaults,noatime,nodiratime 1 2
III Mysql设计优化
III.1存储引擎的选择
Myisam:数据库并发不大,读多写少,而且都能很好的用到索引,sql语句比较简单的应用,TB数据仓库
Innodb:并发访问大,写操作比较多,有外键、事务等需求的应用,系统内存较大。
III.2命名规则
多数开发语言命名规则:比如MyAdress
多数开源思想命名规则:my_address
避免随便命名
III.3字段类型选择
字段类型的选择的一般原则:
根据需求选择合适的字段类型,在满足需求的情况下字段类型尽可能小。
只分配满足需求的最小字符数,不要太慷慨。
原因:更小的字段类型更小的字符数占用更少的内存,占用更少的磁盘空间,占用更少的磁盘IO,以及占用更少的带宽。
III.3.1 整型:
见如下图:
类型
字节
最小值
最大值
(带符号的/无符号的)
(带符号的/无符号的)
TINYINT
1
-128
127
0
255
SMALLINT
2
-32768
32767
0
65535
MEDIUMINT
3
-8388608
8388607
0
16777215
INT
4
-2147483648
2147483647
0
4294967295
BIGINT
8
-9223372036854775808
9223372036854775807
0
18446744073709551615
根据满足需求的最小整数为选择原则,能用INT的就不要用BIGINT。
用无符号INT存储IP,而非CHAR(15)。
III.3.2 浮点型:
类型
字节
精度类型
使用场景
FLOAT(M,D)
4
单精度
精度要求不高,数值比较小
DOUBLE(M,D)(REAL)
8
双精度
精度要求不高,数值比较大
DECIMAL(M,D)(NUMERIC)
M+2
自定义精度
精度要求很高的场景
III.3.3 时间类型
类型
取值范围
存储空间
零值表示法
DATE
1000-01-01~9999-12-31
3字节
0000-00-00
TIME
-838:59:59~838:59:59
3字节
00:00:00
DATETIME
1000-01-01 00:00:00~9999-12-31 23:59:59
8字节
0000-00-00 00:00:00
TIMESTAMP
19700101000000~2037年的某个时刻
4字节
00000000000000
YEAR
YEAR(4):1901~2155 YEAR(2):1970~2069
1字节
0000
III.3.4 字符类型
类型
最大长度
占用存储空间
CHAR[(M)]
M字节
M字节
VARCHAR[(M)]
M字节
M+1字节
TINYBLOD,TINYTEXT
2^8-1字节
L+1字节
BLOB,TEXT
2^16-1字节
L+2
MEDIUMBLOB,MEDIUMTEXT
2^24-1字节
L+3
LONGBLOB,LONGTEXT
2^32-1字节
L+4
ENUM('value1','value2',...)
65535个成员
1或2字节
SET('value1','value2',...)
64个成员
1,2,3,4或8字节
注:L表示可变长度的意思
对于varchar和char的选择要根据引擎和具体情况的不同来选择,主要依据如下原则:
1. 如果列数据项的大小一致或者相差不大,则使用char。
2. 如果列数据项的大小差异相当大,则使用varchar。
3. 对于MyISAM表,尽量使用Char,对于那些经常需要修改而容易形成碎片的myisam和isam数据表就更是如此,它的缺点就是占用磁盘空间。
4. 对于InnoDB表,因为它的数据行内部存储格式对固定长度的数据行和可变长度的数据行不加区分(所有数据行共用一个表头部分,这个标头部分存放着指向各有关数据列的指针),所以使用char类型不见得会比使用varchar类型好。事实上,因为char类型通常要比varchar类型占用更多的空 间,所以从减少空间占用量和减少磁盘i/o的角度,使用varchar类型反而更有利。
5. 表中只要存在一个varchar类型的字段,那么所有的char字段都会自动变成varchar类型,因此建议定长和变长的数据分开。
III.4编码选择
单字节 latin1
多字节 utf8(汉字占3个字节,英文字母占用一个字节)
如果含有中文字符的话最好都统一采用utf8类型,避免乱码的情况发生。
III.5主键选择原则
注:这里说的主键设计主要是针对INNODB引擎
1. 能唯一的表示行。
2. 显式的定义一个数值类型自增字段的主键,这个字段可以仅用于做主键,不做其他用途。
3. MySQL主键应该是单列的,以便提高连接和筛选操作的效率。
4. 主键字段类型尽可能小,能用SMALLINT就不用INT,能用INT就不用BIGINT。
5. 尽量保证不对主键字段进行更新修改,防止主键字段发生变化,引发数据存储碎片,降低IO性能。
6. MySQL主键不应包含动态变化的数据,如时间戳、创建时间列、修改时间列等。
7. MySQL主键应当有计算机自动生成。
8. 主键字段放在数据表的第一顺序。
推荐采用数值类型做主键并采用auto_increment属性让其自动增长。
III.6其他需要注意的地方
NULL OR NOT NULL
尽可能设置每个字段为NOT NULL,除非有特殊的需求,原因如下:
1. 使用含有NULL列做索引的话会占用更多的磁盘空间,因为索引NULL列需要而外的空间来保存。
2. 进行比较的时候,程序会更复杂。
3. 含有NULL的列比较特殊,SQL难优化,如果是一个组合索引,那么这个NULL 类型的字段会极大影响整个索引的效率。
索引
索引的缺点:极大地加速了查询,减少扫描和锁定的数据行数。
索引的缺点:占用磁盘空间,减慢了数据更新速度,增加了磁盘IO。
添加索引有如下原则:
1. 选择唯一性索引。
2. 为经常需要排序、分组和联合操作的字段建立索引。
3. 为常作为查询条件的字段建立索引。
4. 限制索引的数据,索引不是越多越好。
5. 尽量使用数据量少的索引,对于大字段可以考虑前缀索引。
6. 删除不再使用或者很少使用的索引。
7. 结合核心SQL优先考虑覆盖索引。
8. 忌用字符串做主键。
反范式设计
适当的使用冗余的反范式设计,以空间换时间有的时候会很高效。
IV Mysql软件优化
开启mysql复制,实现读写分离、负载均衡,将读的负载分摊到多个从服务器上,提高服务器的处理能力。
使用推荐的GA版本,提升性能
利用分区新功能进行大数据的数据拆分
V Mysql配置优化
注意:全局参数一经设置,随服务器启动预占用资源。
key_buffer_size参数
mysql索引缓冲,如果是采用myisam的话要重点设置这个参数,根据(key_reads/key_read_requests)判断
innodb_buffer_pool_size参数
INNODB 数据、索引、日志缓冲最重要的引擎参数,根据(hit riatos和FILE I/O)判断
wait_time_out参数
线程连接的超时时间,尽量不要设置很大,推荐10s
max_connections参数
服务器允许的最大连接数,尽量不要设置太大,因为设置太大的话容易导致内存溢出,需要通过如下公式来确定:
SET @k_bytes = 1024;
SET @m_bytes = @k_bytes * 1024;
SET @g_bytes = @m_bytes * 1024;
SELECT
(
@@key_buffer_size + @@query_cache_size + @@tmp_table_size+
@@innodb_buffer_pool_size + @@innodb_additional_mem_pool_size+
@@innodb_log_buffer_size+
@@max_connections *
( @@read_buffer_size + @@read_rnd_buffer_size + @@sort_buffer_size+
@@join_buffer_size + @@binlog_cache_size + @@thread_stack
) )
/ @g_bytes AS MAX_MEMORY_USED_GB;
thread_concurrency参数
线程并发利用数量,(cpu+disk)*2,根据(os中显示的请求队列和tickets)判断
sort_buffer_size参数
获得更快的--ORDER BY,GROUP BY,SELECT DISTINCT,UNION DISTINCT
read_rnd_buffer_size参数
当根据键进行分类操作时获得更快的--ORDER BY
join_buffer_size参数
join连接使用全表扫描连接的缓冲大小,根据select_full_join判断
read_buffer_size参数
全表扫描时为查询预留的缓冲大小,根据select_scan判断
tmp_table_size参数
临时内存表的设置,如果超过设置就会转化成磁盘表,根据参数(created_tmp_disk_tables)判断
innodb_log_file_size参数(默认5M)
记录INNODB引擎的redo log文件,设置较大的值意味着较长的恢复时间。
Ø innodb_flush_method参数(默认fdatasync)
Linux系统可以使用O_DIRECT处理数据文件,避免OS级别的cache,O_DIRECT模式提高数据文件和日志文件的IO提交性能
innodb_flush_log_at_trx_commit(默认1)
表示每秒进行一次log写入cache,并flush log到磁盘。
表示在每次事务提交后执行log写入cache,并flush log到磁盘。
表示在每次事务提交后,执行log数据写入到cache,每秒执行一次flush log到磁盘。
VI Mysql语句级优化
1. 性能查的读语句,在innodb中统计行数,建议另外弄一张统计表,采用myisam,定期做统计.一般的对统计的数据不会要求太精准的情况下适用。
2. 尽量不要在数据库中做运算。
3. 避免负向查询和%前缀模糊查询。
4. 不在索引列做运算或者使用函数。
5. 不要在生产环境程序中使用select * from 的形式查询数据。只查询需要使用的列。
6. 查询尽可能使用limit减少返回的行数,减少数据传输时间和带宽浪费。
7. where子句尽可能对查询列使用函数,因为对查询列使用函数用不到索引。
8. 避免隐式类型转换,例如字符型一定要用’’,数字型一定不要使用’’。
9. 所有的SQL关键词用大写,养成良好的习惯,避免SQL语句重复编译造成系统资源的浪费。
10. 联表查询的时候,记得把小结果集放在前面,遵循小结果集驱动大结果集的原则。
11. 开启慢查询,定期用explain优化慢查询中的SQL语句。