标签:mysql

浏览模式: 标准 | 列表 | 图文
MYSQL连载预告

MYSQL连载预告

原来的连载因为一些原因停了N久,从下周开始,每周继续连载。

这次,直至结束。
优化方面的事情以及MYSQL集群等,可能暂时不能涉及
仅涉及MYSQL最基本的一些资料,我想这也应该足够了吧?

利用MySQL Cluster 7.0 + LVS 搭建高可用环境

目录:

1、前言


随着数据量规模的扩大,企业对 MySQL 的要求就不仅仅是能用了,也在寻求各种高可用方案。以前我们的大部分高可用方案其实还存在一定缺陷,例如 MySQL Replication 方案,Master 是否存活检测需要一定时间,而和 Slave 的切换也需要时间,因此其高可用程度较大依赖监控软件或自动化管理工具。而早先的 MySQL Cluster 实在不能令人满意,性能差的不行,也让我们的期待一次次落空。本次 MySQL Cluster 7.0 的推出,终于实现了质的飞跃,性能上得到了很大提高。MySQL Cluster 7.0 新特性主要体现在以下几个方面:

  • 数据节点多线程
  • 可以在线增加节点
  • 大记录存取改进
  • 支持windows平台

本身MySQL Cluster已经实现了高可用,不过由于SQL节点无法对外部负载均衡,因此我们采用 LVS 来实现这一需求。

2、安装


环境描述:

内核:2.6.9-78.0.17.ELsmp
硬件:DELL 2950, 146G 15K RPM SAS * 6(raid 1+0), 8G Ram

各个节点描述:

IP 描述
192.168.0.2 ndb mgm node
192.168.0.3 data node1, sql node 1, LVS DR Server
192.168.0.4 data node2, sql node 2
192.168.0.5 data node3, sql node 3
192.168.0.6 data node4, sql node 4
192.168.0.7 sql node 5
192.168.0.8 sql node 6
192.168.0.9 sql node 7
192.168.0.10 sql node 8

是这样安排这些服务器的,192.168.0.2 作为 MySQL Cluster 的管理节点,2 ~ 6 既做数据节点(DATA node),也做SQL节点(SQL node),7 ~ 10 也做SQL节点。LVS采用 VS/DR 的模式,因此把 192.168.0.2 也同时作为 LVS 的 DR Server。
分配好机器,接下来就是安装响应的软件包了。

2.1 LVS 安装、配置


老实说,我对LVS并不十分在行,以前折腾过一次,差点快崩溃了,后来才发现是我下载的版本太高了,没想到这次也是这样 :(,白折腾了1天。其实过程比较简单,只要下载的版本能对的上就快了。
在这里,我下载的是源码rpm包,因此需要用rpmbuild编译一次。

[yejr@imysql.cn ~]# rpm -ivhU ~/kernel-2.6.9-78.0.17.EL.src.rpm
[yejr@imysql.cn ~]# cd /usr/src/redhat/SPECS
[yejr@imysql.cn ~]# rpmbuild -bp kernel-2.6.spec #解开源码包,打上各种pache
[yejr@imysql.cn ~]# rpm -ivhU ~/ipvsadm-1.24-5.src.rpm #安装ipvsadm的源码包
[yejr@imysql.cn SPECS]# ls
ipvsadm.spec kernel-2.6.spec
#需要做一下链接,编译ipvsadm时用得着
[yejr@imysql.cn SPECS]# ln -s /usr/src/redhat/BUILD/kernel-2.6.9/linux-2.6.9 /usr/src/linux
[yejr@imysql.cn SPECS]# rpm -bb ipvsadm.spec #编译出ipvsadm的rpm包
[yejr@imysql.cn SPECS]# ls -l /usr/src/redhat/RPMS/x86_64/
total 36
-rw-r--r-- 1 root root 30941 May 4 18:06 ipvsadm-1.24-5.x86_64.rpm
-rw-r--r-- 1 root root 2968 May 4 18:06 ipvsadm-debuginfo-1.24-5.x86_64.rpm
[yejr@imysql.cn ~]# rpm -ivhU /usr/src/redhat/RPMS/x86_64/ipvsadm-1.24-5.x86_64.rpm

看到了吧,其实很简单。网上的有些资料说要把 ipvsadm.spec 中的 Copyright 这个 Tag 改成 License,可能是因为版本较老,我用的这个版本就不需要这样。
接下来就是加载 ip_vs 模块,然后开始做 LVS DR 转发了。

[yejr@imysql.cn ~]# /sbin/modprobe ip_vs
[yejr@imysql.cn ~]# lsmod | grep ip_vs
ip_vs 103169 3 ip_vs_rr

直接编辑 /etc/sysconfig/ipvsadm 文件:

[yejr@imysql.cn ~]# cat /etc/sysconfig/ipvsadm
-C
-A -t lvs_vip:mysql -s rr
-a -t lvs_vip:mysql -r ndb_data_node_1:mysql -g -w 1
-a -t lvs_vip:mysql -r ndb_data_node_2:mysql -g -w 1
-a -t lvs_vip:mysql -r ndb_data_node_3:mysql -g -w 1
-a -t lvs_vip:mysql -r ndb_data_node_4:mysql -g -w 1
-a -t lvs_vip:mysql -r ndb_sql_node_1:mysql -g -w 1
-a -t lvs_vip:mysql -r ndb_sql_node_2:mysql -g -w 1
-a -t lvs_vip:mysql -r ndb_sql_node_3:mysql -g -w 1
-a -t lvs_vip:mysql -r ndb_sql_node_4:mysql -g -w 1

保存退出。上面显示的是 hostname 的格式,因为我都在 /etc/hosts 里设置各自对应的 hostname 了。
然后就是在 DR Server 上绑定 vip,然后打开 ip_forward,启动 ipvsadm,LVS 就可以开始工作了。

[yejr@imysql.cn ~]# echo 1 > /proc/sys/net/ipv4/ip_forward #修改内核,打开转发
[yejr@imysql.cn ~]# /sbin/ifconfig eth0:0 192.168.0.11 netmask 255.255.255.0 #绑定vip
[yejr@imysql.cn ~]# /etc/init.d/ipvsadm start #启动ipvsadm
[yejr@imysql.cn ~]# ipvsadm -L #查看列表
ipvsadm -L
IP Virtual Server version 1.2.0 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP lvs_vip:mysql rr
-> gs_ndb_sql_node_1:mysql Route 1 0 0
-> gs_ndb_sql_node_2:mysql Route 1 0 0
-> gs_ndb_sql_node_3:mysql Route 1 0 0
-> gs_ndb_sql_node_4:mysql Route 1 0 0
-> gs_ndb_data_node_1:mysql Route 1 0 0
-> gs_ndb_data_node_2:mysql Route 1 0 0
-> gs_ndb_data_node_3:mysql Route 1 0 0
-> gs_ndb_data_node_4:mysql Route 1 0 0
[yejr@imysql.cn ~]# lsmod | ip_vs #查看已加载模块
lsmod | grep ip_vs
ip_vs_rr 3649 1
ip_vs 103169 3 ip_vs_rr

DR Server 上设置完后,再在 Real Server 上绑定 vip,然后测试,没问题的话,就可以用了。

[yejr@imysql.cn ~]# /sbin/ifconfig lo:0 192.168.0.11 netmask 255.255.255.255 broadcast 192.168.0.11

2.2 MySQL Cluster安装


MySQL Cluster的安装重点在于管理节点的配置文件,只要把配置文件设置好了,其他的就很快了。我在这里是直接用 rpm 包安装的,因为下载整个预编译好的 tar.gz 文件实在太大了,这点上 MySQL 是越来越臃肿了 :(

[yejr@imysql.cn ~]# cat /home/mysql/config.ini
[TCP DEFAULT]
SendBufferMemory=2M
ReceiveBufferMemory=2M
[NDB_MGMD DEFAULT]
PortNumber=1186
Datadir=/home/mysql/
[NDB_MGMD]
id=1
Datadir=/home/mysql/
Hostname=192.168.221.2
[NDBD DEFAULT]
NoOfReplicas=2
Datadir=/home/mysql/
DataMemory=2048M
IndexMemory=1024M
LockPagesInMainMemory=1
MaxNoOfConcurrentOperations=100000
StringMemory=25
MaxNoOfTables=4096
MaxNoOfOrderedIndexes=2048
MaxNoOfUniqueHashIndexes=512
MaxNoOfAttributes=24576
DiskCheckpointSpeedInRestart=100M
FragmentLogFileSize=256M
InitFragmentLogFiles=FULL
NoOfFragmentLogFiles=6
RedoBuffer=32M
TimeBetweenLocalCheckpoints=20
TimeBetweenGlobalCheckpoints=1000
TimeBetweenEpochs=100
MemReportFrequency=30
BackupReportFrequency=10
### Params for setting logging
LogLevelStartup=15
LogLevelShutdown=15
LogLevelCheckpoint=8
LogLevelNodeRestart=15
### Params for increasing Disk throughput
BackupMaxWriteSize=1M
BackupDataBufferSize=16M
BackupLogBufferSize=4M
BackupMemory=20M
#Reports indicates that odirect=1 can cause io errors (os err code 5) on some systems. You must test.
#ODirect=1
### Watchdog
TimeBetweenWatchdogCheckInitial=30000
### TransactionInactiveTimeout - should be enabled in Production
#TransactionInactiveTimeout=30000
### CGE 6.3 - REALTIME EXTENSIONS
#RealTimeScheduler=1
#SchedulerExecutionTimer=80
#SchedulerSpinTimer=40
### DISK DATA
#SharedGlobalMemory=384M
#read my blog how to set this:
#DiskPageBufferMemory=3072M
### Multithreading
MaxNoOfExecutionThreads=8
[NDBD]
id=2
Datadir=/home/mysql/
Hostname=192.168.221.3
#LockExecuteThreadToCPU=X
#LockMaintThreadsToCPU=Y
[NDBD]
id=3
Datadir=/home/mysql/
Hostname=192.168.221.4
#LockExecuteThreadToCPU=X
#LockMaintThreadsToCPU=Y
[NDBD]
id=4
Datadir=/home/mysql/
Hostname=192.168.221.5
#LockExecuteThreadToCPU=X
#LockMaintThreadsToCPU=Y
[NDBD]
id=5
Datadir=/home/mysql/
Hostname=192.168.221.6
#LockExecuteThreadToCPU=X
#LockMaintThreadsToCPU=Y
[MYSQLD]
id=6
Hostname=192.168.221.3
[MYSQLD]
id=7
Hostname=192.168.221.4
[MYSQLD]
id=8
Hostname=192.168.221.5
[MYSQLD]
id=9
Hostname=192.168.221.6
[MYSQLD]
id=10
Hostname=192.168.221.7
[MYSQLD]
id=11
Hostname=192.168.221.8
[MYSQLD]
id=12
Hostname=192.168.221.9
[MYSQLD]
id=13
Hostname=192.168.221.10

然后启动 ndb_mgmd 进程:

[yejr@imysql.cn ~]# /usr/sbin/ndb_mgmd -f /home/mysql/config.ini --configdir=/home/mysql/

如果是修改了配置文件里的某些参数,则需要先关闭 ndb_mgmd 进程,然后重新启动,不过必须加上 --reload 选项,因为 7.0 版本中,会把配置文件放在 cache 里,如果不注意到这点,可能会被搞得莫名其妙的。

[yejr@imysql.cn ~]# /usr/sbin/ndb_mgmd -f /home/mysql/config.ini --configdir=/home/mysql/ --reload

然后在数据节点上启动 ndbd 进程:

[yejr@imysql.cn ~]# /usr/sbin/ndbd --initial

首次启动,需要加上 --initial 选项,其后的启动后就不需要了。
最后,修改SQL节点上的配置文件 my.cnf,然后启动 mysqld 进程:

[yejr@imysql.cn ~]# cat /etc/my.cnf
#my.cnf
[mysql_cluster]
ndb-connectstring="192.168.221.2:1186"
[MYSQLD]
......
ndb-cluster-connection-pool=1
ndbcluster
ndb-connectstring="192.168.221.2:1186"
ndb-force-send=1
ndb-use-exact-count=0
ndb-extra-logging=1
ndb-autoincrement-prefetch-sz=256
engine-condition-pushdown=1
......
[yejr@imysql.cn ~]# /etc/init.d/mysql start
[yejr@imysql.cn ~]# mysqladmin pr
+------+-------------+-----------+----+---------+------+-----------------------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+------+-------------+-----------+----+---------+------+-----------------------------------+------------------+
| 1 | system user | | | Daemon | 0 | Waiting for event from ndbcluster | |
| 1579 | root | localhost | | Query | 0 | | show processlist |
+------+-------------+-----------+----+---------+------+-----------------------------------+------------------+

在管理节点上看下 cluster 的状态:

[yejr@imysql.cn ~]# ndb_mgm
-- NDB Cluster -- Management Client --
ndb_mgm> show
Connected to Management Server at: localhost:1186
Cluster Configuration
---------------------
[ndbd(NDB)] 4 node(s)
id=2 @192.168.221.3 (mysql-5.1.32 ndb-7.0.5, Nodegroup: 0, Master)
id=3 @192.168.221.4 (mysql-5.1.32 ndb-7.0.5, Nodegroup: 0)
id=4 @192.168.221.5 (mysql-5.1.32 ndb-7.0.5, Nodegroup: 1)
id=5 @192.168.221.6 (mysql-5.1.32 ndb-7.0.5, Nodegroup: 1)
[ndb_mgmd(MGM)] 1 node(s)
id=1 @192.168.221.2 (mysql-5.1.32 ndb-7.0.5)
[mysqld(API)] 10 node(s)
id=6 @192.168.221.3 (mysql-5.1.32 ndb-7.0.5)
id=7 @192.168.221.4 (mysql-5.1.32 ndb-7.0.5)
id=8 @192.168.221.5 (mysql-5.1.32 ndb-7.0.5)
id=9 @192.168.221.6 (mysql-5.1.32 ndb-7.0.5)
id=10 @192.168.221.7 (mysql-5.1.32 ndb-7.0.5)
id=13 @192.168.221.8 (mysql-5.1.32 ndb-7.0.5)
id=14 @192.168.221.9 (mysql-5.1.32 ndb-7.0.5)
id=15 @192.168.221.10 (mysql-5.1.32 ndb-7.0.5)
ndb_mgm> exit

可以看到,一切正常。

3、测试


我们主要进行一下对比测试,看看新版本的 ndbcluster 引擎相对 MyISAM 和 InnoDB 到底区别多大。

3.1 mysqlslap测试结果



纵坐标是总共运行时间。
mysqlslap完整执行参数类似下面:

mysqlslap -hlocalhost -uroot --engine=myisam --auto-generate-sql-write-number=100000 --auto-generate-sql-guid-primary \
--concurrency=50,100,200 --number-of-queries=500000 --iterations=2 --number-char-cols=10 --number-int-cols=10 \
--auto-generate-sql --create-schema=ndb --auto-generate-sql-load-type=mixed

3.2 sysbench测试结果



纵坐标是每秒运行的事务数。
sysbench完整执行参数类似下面:

sysbench --mysql-user=root --test=oltp --mysql-host=localhost --oltp-test-mode=complex \
--mysql-table-engine=ndbcluster --oltp-table-size=10000000 --mysql-db=ndb --oltp-table-name=mdb_1kw \
--num-threads=200 --max-requests=500000 run

从上面的测试结果我们也可以看到,单独的mysqld实例下,MyISAM适合并发很小的业务,InnoDB适合类似连接池模式下的高 并发业务,不适合非常大并发的情景,而采用了LVS后的ndbcluster则是真正的适合高并发环境,尽管其性能相对InnoDB来说不是太好,不过比 以往版本也已经提升了很多,用于正式生产环境的时候真是指日可待了。

oracle收购sun

oracle收购sun

这段时间最大的新闻莫过于SUN被收购了,收购人不是IBM而是oracle
新闻那是铺天盖地呀,去CNBETA看看就知道了,但对于我来说,关心的只有几点:

1、MYSQL会怎么个走法?
2、以后java会怎么继续
3、服务器价格会下降吗?

更多新闻请google一下就知道了

老王:如何修复损坏的MyISAM表

myisam如果经常insert,update,delete会产生很多的碎片,而且因为表类型的关系,其实它如果使用不当,也会有损坏的情况发生,一般情况下,可以使用repair table来进行修复。老王说,尽量使用 myisamchk来进行修复,因为这是命令行下的,所以,我没有用过。命令行下,我用的也是repair table。
所以,我转载了老王的这篇博客,写完后,老王又来了一篇TableCache设置过小造成MyISAM频繁损坏,看来,myisam表之所以容易损坏,和tablecache的设置还是有关的。

修复表的原文如下:
当我们用PHPMyAdmin浏览数据库时,有时候会发现某些MyISAM表的Collation项显示为“in use”,这多半说明此表已经损坏。即便是没有出现“in use”字样,也不能就此说明表是完好无损的,熟悉检查及修复方法是必须的。

通过语句:

检查表使用CHECK TABLE语句,如下:

CHECK TABLE tbl_name [, tbl_name] ... [option] ...
option = {FOR UPGRADE | QUICK | FAST | MEDIUM | EXTENDED | CHANGED}

修复表使用REPAIR TABLE语句,如下:

REPAIR [NO_WRITE_TO_BINLOG | LOCAL] TABLE
tbl_name [, tbl_name] ...
[QUICK] [EXTENDED] [USE_FRM]

通过命令:

检查修复表可以使用myisamchk命令:

myisamchk [options] tbl_name ...

如果没有指定参数,那么myisamchk命令缺省执行的就是检查动作。若是要修复表,可以使用-r或-o参数,应该优先使用-r修复,不行的话再使用-o修复。此外,在修复前应该使用FLUSH TABLES刷新缓存,并关闭数据库服务器或者锁定所有的待修复表,以确保在修复过程中不会有其他写操作。

自动修复:

在my.cnf配置文件中的mysqld部分设定myisam-recover参数,当服务启动时可以自动修复有问题的表(速度快慢视数据多少):

[mysqld]
myisam-recover [= options]

参数有DEFAULT,BACKUP,FORCE,QUICK,可以设定为BACKUP,FORCE,万万不可单独设置成FORCE,否则数据文件丢了都没处哭去。


应该尽量使用myisamchk命令去修复,不行再用repair语句去修复(慢),还不行就参考下面链接。

参考文档:How to Repair Tables
而对于tablecache的设定,老王建议:如果你比较懒惰,也可以用MySQL Performance Tuning Primer Script来判断参数是否合理

你可能不知道的MySQL

你可能不知道的MySQL

冰山上的博客,更新速度之快,令我乍叹不已,我以为我算是勤劳的,想不到,他更是属于勤劳中的勤劳分子。。

以下内容又是COPY于他的网站,看来,他关注的部分内容还是比我高档,我仍然沉迷于一些小技巧,而忽略了一些大的东西。

心有多大,舞台有多大,其实这对技术人员来说非常重要,如果你只注重于一小块技术,那么在大的方面,你永远不会有进步。
扯远了。。不过以下一些小技巧我真的大部分都没有用过,所以我才会贴出来,让大家一起学习一下,如果知道的就直接跳过,当我没说。

内容如下:http://xinsync.xju.edu.cn/index.php/archives/4719

前言:

实验的数据表如下定义:

mysql> desc tbl_name;
+-------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+--------------+------+-----+---------+-------+
| uid | int(11) | NO | | NULL | |
| sid | mediumint(9) | NO | | NULL | |
| times | mediumint(9) | NO | | NULL | |
+-------+--------------+------+-----+---------+-------+
3 rows in set (0.00 sec)

存储引擎是MyISAM,里面有10,000条数据。

一、”\G”的作用

mysql> select * from tbl_name limit 1;
+--------+--------+-------+
| uid | sid | times |
+--------+--------+-------+
| 104460 | 291250 | 29 |
+--------+--------+-------+
1 row in set (0.00 sec)

mysql> select * from tbl_name limit 1\G;
*************************** 1. row ***************************
uid: 104460
sid: 291250
times: 29
1 row in set (0.00 sec)

有时候,操作返回的列数非常多,屏幕不能一行显示完,显示折行,试试”\G”,把列数据逐行显示(”\G”挽救了我,以前看explain语句横向显示不全折行看起来巨费劲,还要把数据和列对应起来)。

二、”Group by”的”隐形杀手”

mysql> explain select uid,sum(times) from tbl_name group by uid\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: tbl_name
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 10000
Extra: Using temporary; Using filesort
1 row in set (0.00 sec)

mysql> explain select uid,sum(times) from tbl_name group by uid order by null\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: tbl_name
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 10000
Extra: Using temporary
1 row in set (0.00 sec)

默认情况下,Group by col会对col字段进行排序,这就是为什么第一语句里面有Using filesort的原因,如果你不需要对col字段进行排序,加上order by null吧,要快很多,因为filesort很慢的。

三、大批量数据插入

最高效的大批量插入数据的方法:

load data infile ‘/path/to/file’ into table tbl_name;

如果没有办法先生成文本文件或者不想生成文本文件,可以一次插入多行:

insert into tbl_name values (1,2,3),(4,5,6),(7,8,9)…

注意一条sql语句的最大长度是有限制的。如果还不想这样,可以试试MySQL的prepare,应该都会比硬生生的逐条插入要快许多。

如果数据表有索引,建议先暂时禁用索引:

alter table tbl_name disable keys;

插入完毕之后再激活索引:

alter table tbl_name enable keys;

对MyISAM表尤其有用。避免每插入一条记录系统更新一下索引。

四、最快复制表结构方法

mysql> create table clone_tbl select * from tbl_name limit 0;
Query OK, 0 rows affected (0.08 sec)

只会复制表结构,索引不会复制,如果还要复制数据,把limit 0去掉即可。

五、加引号和不加引号区别

给数据表tbl_name添加索引:

mysql> create index uid on tbl_name(uid);

测试如下查询:

mysql> explain select * from tbl_name where uid = '1081283900'\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: tbl_name
type: ref
possible_keys: uid
key: uid
key_len: 4
ref: const
rows: 143
Extra:
1 row in set (0.00 sec)

我们在整型字段的值上加索引,是可以用到索引的,网上不少人误传在整型字段上加引号无法使用索引。修改uid字段类型为varchar(12):

mysql> alter table tbl_name change uid uid varchar(12) not null;

测试如下查询:

mysql> explain select * from tbl_name where uid = 1081283900\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: tbl_name
type: ALL
possible_keys: uid
key: NULL
key_len: NULL
ref: NULL
rows: 10000
Extra: Using where
1 row in set (0.00 sec)

我们在查询值上不加索引,结果索引无法使用,注意安全。

六、前缀索引

有时候我们的表中有varchar(255)这样的字段,而且我们还要对该字段建索引,一般没有必要对整个字段建索引,建立前8~12个字符的索引应该就够了,很少有连续8~12个字符都相等的字段。

为什么?更短的索引意味索引更小、占用CPU时间更少、占用内存更少、占用IO更少和很更好的性能。

七、MySQL索引使用方式

MySQL在一个查询中只能用到一个索引(5.0以后版本引入了index_merge合并索引,对某些特定的查询可以用到多个索引,具体查考[中文] [英文]),所以要根据查询条件建立联合索引,联合索引只有第一位的字段在查询条件中能才能使用到。

如果MySQL认为不用索引比用索引更快的话,那么就不会用索引。

mysql> create index times on tbl_name(times);
Query OK, 10000 rows affected (0.10 sec)
Records: 10000 Duplicates: 0 Warnings: 0

mysql> explain select * from tbl_name where times > 20\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: tbl_name
type: ALL
possible_keys: times
key: NULL
key_len: NULL
ref: NULL
rows: 10000
Extra: Using where
1 row in set (0.00 sec)

mysql> explain select * from tbl_name where times > 200\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: tbl_name
type: range
possible_keys: times
key: times
key_len: 3
ref: NULL
rows: 1599
Extra: Using where
1 row in set (0.00 sec)

数据表中times字段绝大多数都比20大,所以第一个查询没有用索引,第二个才用到索引.

何时升级硬件,何时更新配置

何时升级硬件,何时更新配置

一直在关注着MYSQL的优化工作,但却也从来没有从硬件方面进行过探讨,前段时间有人在群里贴了一个msyql部落的链接,跑上去偷偷看了两眼,发现还是有点料的。以下就是其中的一点料:

http://www.mysqlsystems.com/?p=3

以前一直在MySQL的本家做咨询工作,所以我下面和大家讨论的话题是一个我在工作中经常遇到的问题。

什么时候我们应该升级硬件?什么时候应该修改配置?

作为DBA,老板和公司总是希望我们以最小的投入换来最大的性能(效益)。不过我并没有暗示大家,我接下讨论的话题,会是让各位避免购买硬件。

对于上面的答案很多人肯定会说两者都做,或者只做配置修改。我想我没有给大家出选择题,只是拿出来做任何一个考虑的时候,哪些因素影响着我们。我的回答经常是:

1.使劲优化MySQL服务器和查询语句

先看看别人的例子,或者仔细读一些MySQL的手册吧,这样你可以优化一些非常简单的my.cnf。也许最简单的index提高了几十倍的性能。不要轻易买硬件!

2. 先看看你的硬件整体架构是否平衡?

这个问题比较复杂,需要配合你的系统管理员来做,比较小的公司可能是一个人包了 这两个角色。我曾经去过一个沈阳的ISV那边,他们是一个大数据量,并发的使用MySQL。后来随着业务增加,其中三台IBM的P机放数据库的机器负担非 常重,后来老板下死令要dba调性能。DBA在尝试了很多种手册上的方法后,均无明显效果。后来在很多次交流以后才得知,他们信息中心还有4台机器跑着 Mail服务器,任务量非常轻。在建议他们利用上这些机器可能配置的情况下,性能很快就上去了

3. 没办法,服务器全用上了?

这种情况也非常常见,特别是对于那些服务器24小时都有人访问的web公司,如 youtube。如果用一些性能监视工具去监控整个服务器,结果看看一整天的流量和性能图,可能会大跌眼镜,服务并不是每时每刻都非常慢,而是某个特定时 间段,排除网络的原因,服务器备份的时候或者DBA下班的时候设置的半夜Cron工作总是对数据库有非常大的压力。

4. 还是买硬件吧,有什么建议?

性能调优有句老话,没有最好只有更好。一个系统的性能出现问题,是各个环节的累计造成的。用微观经济学的说法就是我们要使用边际成本最高的投入。

下面几种情况可以考虑相应的部件升级,经济危机了,整机成本太高而且是在没有必要。

IO读写太多,也许考虑买一条200块的内存?
增加CPU运算,也许考虑买一台x86的服务器,忘记Sun的CMT吧,因为MySQL的限制,使用不了这么多线程,反倒增加负担。

MYSQL字段注释

MYSQL字段注释

本内容来自群聊天记录,开花石头吐出来的。。。

取字段注释

SELECT COLUMN_NAME 列名, DATA_TYPE 字段类型, COLUMN_COMMENT 字段注释
FROM INFORMATION_SCHEMA.COLUMNS
WHERE table_name = 'companies'##表名
AND table_schema = 'testhuicard'##数据库名
AND column_name LIKE 'c_name'##字段名

SELECT table_name 表名,TABLE_COMMENT 表注释 FROM INFORMATION_SCHEMA.TABLES WHERE table_schema = 'testhuicard' ##数据库名

AND table_name LIKE 'companies'##表名



参考http://dev.mysql.com/doc/refman/5.1/zh/ 今天找到了取mysql表和字段注释的语句

[转摘]如何利用MySQL加密函数保护Web网站敏感数据

[转摘]如何利用MySQL加密函数保护Web网站敏感数据

原文:http://www.javauu.com/thread-4678-1-1.html
如果您正在运行使用MySQL的Web应用程序,那么它把密码或者其他敏感信息保存在应用程序里的机会就很大。保护这些数据免受黑客或者窥探者的获取是一个令人关注的重要问题,因为您既不能让未经授权的人员使用或者破坏应用程序,同时还要保证您的竞争优势。幸运的是,MySQL带有很多设计用来提供这种类型安全的加密函数。本文概述了其中的一些函数,并说明了如何使用它们,以及它们能够提供的不同级别的安全。

双向加密

就让我们从最简单的加密开始:双向加密。在这里,一段数据通过一个密钥被加密,只能够由知道这个密钥的人来解密。MySQL有两个函数来支持这种类型的加密,分别叫做ENCODE()和DECODE()。下面是一个简单的实例:

mysql> INSERT INTO users (username, password) VALUES ('joe', ENCODE('guessme', 'abracadabra'));
Query OK, 1 row affected (0.14 sec)

其中,Joe的密码是guessme,它通过密钥abracadabra被加密。要注意的是,加密完的结果是一个二进制字符串,如下所示:

mysql> SELECT * FROM users WHERE username='joe';
+----------+----------+
| username | password |
+----------+----------+
| joe | ¡?i??!? |
+----------+----------+
1 row in set (0.02 sec)

abracadabra这个密钥对于恢复到原始的字符串至关重要。这个密钥必须被传递给DECODE()函数,以获得原始的、未加密的密码。下面就是它的使用方法:

mysql> SELECT DECODE(password, 'abracadabra') FROM users WHERE username='joe';
+---------------------------------+
| DECODE(password, 'abracadabra') |
+---------------------------------+
| guessme |
+---------------------------------+
1 row in set (0.00 sec)

应该很容易就看到它在Web应用程序里是如何运行的――在验证用户登录的时候,DECODE()会用网站专用的密钥解开保存在数据库里的密码,并和用户输入的内容进行对比。假设您把PHP用作自己的脚本语言,那么可以像下面这样进行查询:

$query = "SELECT COUNT(*) FROM users WHERE username='$inputUser' AND DECODE(password, 'abracadabra') = '$inputPass'";?>

提示:虽然ENCODE()和DECODE()这两个函数能够满足大多数的要求,但是有的时候您希望使用强度更高的加密手段。在这种情况下,您可以使用AES_ENCRYPT()和AES_DECRYPT()函数,它们的工作方式是相同的,但是加密强度更高。

单向加密

单向加密与双向加密不同,一旦数据被加密就没有办法颠倒这一过程。因此密码的验证包括对用户输入内容的重新加密,并将它与保存的密文进行比对,看是否匹配。一种简单的单向加密方式是MD5校验码。MySQL的MD5()函数会为您的数据创建一个“指纹”并将它保存起来,供验证测试使用。下面就是如何使用它的一个简单例子:

mysql> INSERT INTO users (username, password) VALUES ('joe', MD5('guessme'));
Query OK, 1 row affected (0.00 sec)
mysql> SELECT * FROM users WHERE username='joe';
+----------+----------------------------------+
| username | password |
+----------+----------------------------------+
| joe | 81a58e89df1f34c5487568e17327a219 |
+----------+----------------------------------+
1 row in set (0.02 sec)

现在您可以测试用户输入的内容是否与已经保存的密码匹配,方法是取得用户输入密码的MD5校验码,并将它与已经保存的密码进行比对,就像下面这样:

mysql> SELECT COUNT(*) FROM users WHERE username='joe' AND password=MD5('guessme');
+----------+
| COUNT(*) |
+----------+
| 1 |
+----------+
1 row in set (0.00 sec)

或者,您考虑一下使用ENCRYPT()函数,它使用系统底层的crypt()系统调用来完成加密。这个函数有两个参数:一个是要被加密的字符串,另一个是双(或者多)字符的“salt”。它然后会用salt加密字符串;这个salt然后可以被用来再次加密用户输入的内容,并将它与先前加密的字符串进行比对。下面一个例子说明了如何使用它:

mysql> INSERT INTO users (username, password) VALUES ('joe', ENCRYPT('guessme', 'ab'));
Query OK, 1 row affected (0.00 sec)
mysql> SELECT * FROM users WHERE username='joe';
+----------+---------------+
| username | password |
+----------+---------------+
| joe | ab/G8gtZdMwak |
+----------+---------------+
1 row in set (0.00 sec)

结果是

mysql> SELECT COUNT(*) FROM users WHERE username='joe' AND password=ENCRYPT('guessme', 'ab');
+----------+
| COUNT(*) |
+----------+
| 1 |
+----------+
1 row in set (0.00 sec)

提示:ENCRYPT()只能用在*NIX系统上,因为它需要用到底层的crypt()库。

幸运的是,上面的例子说明了能够如何利用MySQL对您的数据进行单向和双向的加密,并告诉了您一些关于如何保护数据库和其他敏感数据库信息安全的理念。

关于set names

关于set names

一般我们在设置数据库字符集的时候,都是用mysql_query('set names utf8')这样来处理,但其实这样处理的不全,象discuz等都是采用了全部的操作,它是这样的:mysql_query('character_set_connection=utf8, character_set_results=utf8 character_set_client=binary'),也只有这样,才会比较全面。
仔细看手册 ,手册上也这样写着:
  Note: This is the preferred way to change the charset. Using mysql_query() to execute SET NAMES .. is not reccomended.

那么,我们该怎么处理呢?从PHP5.2.3开始多了一个函数,它就是:mysql_set_charset,你可以:

<?
$conn = .... //假设这是连接后的 resource ID
if( mysql_client_encoding ( $conn) != 'utf8' ){
mysql_set_charset('utf8');
}
这样才是比较推荐的用法。不过,这样的用法也是有要求的,手册告诉我们:

Note: This function requires MySQL 5.0.7 or later.

传说需要采用这样的方法,是因为set names在某些字符集的时候有安全隐患。

小议mysql变量及其优化

小议mysql变量及其优化

本文属摘抄文章,以作备份

原文地址为:http://www.tbqu.com/post/251.html

mysql里的变量分系统变量和用户变量.
系统变量
其中系统变量,又分全局(global)和会话(session)两种.
全局系统变量,主要影响整个mysql实例的全局设置.
大部分变量都是作为mysql的服务器调节参数存在.新增或修改这类变量, 会影响mysql的运行方式.
比如: auto_increment_increment 代表序列的自增值, 默认为1

另外, mysql中,只有一部分变量是支持运行时动态修改的.
变量修改的作用范围,是那些重新创建连接到mysql服务器的客户端连接.

如果你的连接是由应用通过连接池来维护的,并且,是长连接的,那么,此时在服务器运行过程中,动态地修改全局变量对你是没有什么影响的.

通过全局变量, 我们可以想到一些应用场景:
1, 在存储过程, 函数, sql里,使用一些业务相关的全局变量.
经常编写业务相关的存储过程,函数的朋友, 可能会需要针对不同业务,设置能共享访问的全局变量.

比如, 公司的总人数,很多存储过程都需要调用这个值,但是因为这个值,不是经常会改变的,不需要每次都count.
所以大多数人会考虑把它cache一把,那么mysql提供的全局变量,就是一个好的存储场所.

2, 数据库配置中心

首先,这不一定是一种好的解决方式, 特别是大型地分布式系统.但是想到了,就跟大家分享一下.
主要就是利用了三层,四层架构的系统, 必不可少的数据库层来实现的.

大家知道, 应用的配置, 大多数是用配置文件或配置服务器来实现, 前者需要跟着项目打包, 部署.
后者, 只要在应用初始化或运行时,去配置中心取配置就行了.(淘宝这边两者都在用)

而数据库的配置中心, 其实类似配置服务器, 只不过灵活运用了mysql的变量机制.
它能继承配置服务器的多数优点, 但最大的特色就是在 sql, function , procedure 里都可以很方便地引用到.(相比用表的方式, 要方便一些)
并且本身就具有缓存, 移植得话, mysql得导出也是很快.
所以小系统, 想快速得搭建一个配置中心,利用mysql感觉还是不错的.

调用语法:
select * from user_info where id = @@global.admin_id — 例子,通过全局里配置的管理员id来取用户信息

以下是全局变量的一些常用命令,比较简单:
set global auto_increment_increment=1; — 设置序列的增长值
show global variables; — 显示所有的global变量
show global variables like ‘%test%’ — 查询包含test字符串的global变量

会话系统变量, 主要用于在当前客户端连接的生命周期内.它的变量值是全局变量的一份拷贝.
如果连接断开, 对当前会话变量所做修改都会被重置.

比如, 服务器会话变量 autocommit 默认为 true , 而你在非常连的客户端连接里设置了 false , 那么在执行完sql后, 连接就会断开. 此后,如果创建新的连接来执行sql, autocommit又会默认 true.

会话变量的使用场景与全局类似,只是生命周期不同, 因此可以用来
统计同一连接内请求sql次数, sql类型等信息.

session变量的一些常用操作:
set session auto_increment_increment=1; — 设置序列的增长值
show variables; or show session variables; — 如果不指明, 默认使用session变量
show variables like ‘%test%’ or show session variables lile ‘%test%’ — 查询包含test字符串的session变量

用户变量
基于会话变量实现的, 可以暂存值, 并传递给同一连接里的下一条sql使用的变量.
当客户端连接退出时,变量会被释放.

应用场景:
同一连接,未关闭情况下,帮你暂存一些计算结果.

比如
select @admin_id:=max(id) from user_info;
select * from user_info where id = @admin_id
以上两条sql在同一connection中完成.
另外,注意,用户变量前只有1个@, 2个@是用于存取系统变量的
业务相关的变量定义太多,无法区分系统全局变量?

这类问题,可以通过mysql提供的结构化系统变量来解决.

他们有独特的表示形式:
instance_name.test_var

比一般的变量多了一个instance_name.这样,你就可以很方便地对他们进行分类,比如 app.test_var,就可以区别于系统的var了.

PS: 其实,普通的系统变量,它也属于结构化变量,只不过他们默认隶属于 default 这个 instance, 不需要显示出来罢了.
影响mysql性能的系统变量
以下内容参考 http://www.mysqlperformanceblog.com/2006/06/08/mysql-server-variables-sql-layer-or-storage-engine-specific/

bulk_insert_buffer_size

批量插入缓存大小, 这个参数是针对MyISAM存储引擎来说的.适用于在一次性插入100-1000+条记录时, 提高效率.默认值是8M.可以针对数据量的大小,翻倍增加.

concurrent_insert
并发插入, 当表没有空洞(删除过记录), 在某进程获取读锁的情况下,其他进程可以在表尾部进行插入.
值可以设0不允许并发插入,1当表没有空洞时,执行并发插入,2.不管是否有空洞都执行并发插入.
默认是1.针对表的删除频率来设置.

delay_key_write

针对MyISAM存储引擎,延迟更新索引.意思是说,update记录时,先将数据up到磁盘,但不up索引,将索引存在内存里,当表关闭时,将内存索引,写到磁盘. 值为 0不开启, 1开启. 默认开启.

delayed_insert_limit, delayed_insert_timeout, delayed_queue_size
延迟插入, 将数据先交给内存队列, 然后慢慢地插入.但是这些配置,不是所有的存储引擎都支持, 目前来看, 常用的InnoDB不支持, MyISAM支持. 根据实际情况调大, 一般默认够用了.

expire_logs_days

自动删除超过指定天数的日志. 建议为0,表示“不自动删除”.

flush, flush_time

是否启用, 同步表数据到磁盘.以及自动同步的间隔时间.
针对flush_time, 官方建议只在Windows 9x或Me,或有最小资源的系统中使用该选项.所以,建议关闭.

ft_boolean_syntax, ft_max_word_len, ft_min_word_len,ft_query_expansion_limit, ft_stopword_file

针对MyISAM设置的参数, 全文搜索特性. 如果你不使用 FULLTEXT 索引,就不需要优化了. 详见mysql参考手册.

join_buffer_size

用于表间关联(join)的缓存大小.建议设为 131072.(128K)

key_buffer_size

索引块缓存区大小, 针对MyISAM存储引擎,该值越大,性能越好.但是超过操作系统能承受的最大值,反而会使mysql变得不稳定.
如果不是MyISAM存储引擎,一般设置为 4-32M大小.

key_cache_age_threshold, key_cache_block_size, key_cache_division_limit

键值缓存的相关设置.需要针对实际情况调优.只是针对MyISAM储存引擎.

large_pages

是否启动大页面支持.意思是,可以一些缓存分配更大的空间.这个特性已经被InnoDB, MyISAM等常用存储引擎支持.

low_priority_updates

低优先级更新.意思是, 所有的写操作(表写锁), 包括update,delete,insert等都需要等待读操作完成后才执行 (表读锁解开).
因为是针对表的锁,所以,这里仅支持MyISAM.

max_write_lock_count

最大写锁数量.这个变量的含义是, 当写锁达到一定数量后, 就不限制读锁, 允许一部分读锁进入.(可以读数据了,否则需要等待写锁释放后,才能读)

因为是针对表的锁,所以,这里仅支持MyISAM.

preload_buffer_size

重载索引时分配的缓冲区大小, 该变量仅支持MyISAM.

read_buffer_size, read_rnd_buffer_size

每个线程连续扫描时为扫描的每个表分配的缓冲区的大小(字节)。如果进行多次连续扫描,可能需要增加该值, 默认值为131072。

sort_buffer_size

每个排序线程分配的缓冲区的大小。增加该值可以加快ORDER BY或GROUP BY操作.默认数值是2097144(2M),建议加大到 16777208 (16M)。

timed_mutexes

显示mutexes的统计信息, 默认关闭OFF

tmp_table_size

临时表的大小,在未超过大小之前进行的操作是在内存中的, 当超过后,mysql会自动转换到硬盘上.