MySQL的sql_mode解析与设置

解析

这个sql_mode,简而言之就是:它定义了你MySQL应该支持的sql语法,对数据的校验等等。。

一、如何查看当前数据库使用的sql_mode:

mysql> select @@sql_mode;

如下是我的数据库当前的模式:

二、sql_mode值的含义:

ONLY_FULL_GROUP_BY:

对于GROUP BY聚合操作,如果在SELECT中的列,没有在GROUP BY中出现,那么将认为这个SQL是不合法的,因为列不在GROUP BY从句中

STRICT_TRANS_TABLES:

在该模式下,如果一个值不能插入到一个事务表中,则中断当前的操作,对非事务表不做任何限制

NO_ZERO_IN_DATE:

在严格模式,不接受月或日部分为0的日期。如果使用IGNORE选项,我们为类似的日期插入’0000-00-00’。在非严格模式,可以接受该日期,但会生成警告。

NO_ZERO_DATE:

在严格模式,不要将 ‘0000-00-00’做为合法日期。你仍然可以用IGNORE选项插入零日期。在非严格模式,可以接受该日期,但会生成警告

ERROR_FOR_DIVISION_BY_ZERO:

在严格模式,在INSERT或UPDATE过程中,如果被零除(或MOD(X,0)),则产生错误(否则为警告)。如果未给出该模式,被零除时MySQL返回NULL。如果用到INSERT IGNORE或UPDATE IGNORE中,MySQL生成被零除警告,但操作结果为NULL。

NO_AUTO_CREATE_USER

防止GRANT自动创建新用户,除非还指定了密码。

NO_ENGINE_SUBSTITUTION:

如果需要的存储引擎被禁用或未编译,那么抛出错误。不设置此值时,用默认的存储引擎替代,并抛出一个异常

另外还有一些,这里仅对我本地当前值做解释分析。。。。。

三、据说是MySQL5.0以上版本支持三种sql_mode模式:ANSI、TRADITIONAL和STRICT_TRANS_TABLES。

1、ANSI模式:宽松模式,更改语法和行为,使其更符合标准SQL。对插入数据进行校验,如果不符合定义类型或长度,对数据类型调整或截断保存,报warning警告。对于本文开头中提到的错误,可以先把sql_mode设置为ANSI模式,这样便可以插入数据,而对于除数为0的结果的字段值,数据库将会用NULL值代替。

将当前数据库模式设置为ANSI模式:

mysql> set @@sql_mode=ANSI;

2、TRADITIONAL模式:严格模式,当向mysql数据库插入数据时,进行数据的严格校验,保证错误数据不能插入,报error错误,而不仅仅是警告。用于事物时,会进行事物的回滚。 注释:一旦发现错误立即放弃INSERT/UPDATE。如果你使用非事务存储引擎,这种方式不是你想要的,因为出现错误前进行的数据更改不会“滚动”,结果是更新“只进行了一部分”。

将当前数据库模式设置为TRADITIONAL模式:

mysql> set @@sql_mode=TRADITIONAL;

3、STRICT_TRANS_TABLES模式:严格模式,进行数据的严格校验,错误数据不能插入,报error错误。如果不能将给定的值插入到事务表中,则放弃该语句。对于非事务表,如果值出现在单行语句或多行语句的第1行,则放弃该语句。

将当前数据库模式设置为STRICT_TRANS_TABLES模式:

mysql> set @@sql_mode=STRICT_TRANS_TABLES;

没有最好与最坏的模式,只有最合适的模式。需要根据自己的实际情况去选择那个最适合的模式!!!

另外说一点,这里的更改数据库模式都是session级别的,一次性,关了再开就不算数了!!!

也可以通过配置文件设置:vim /etc/my.cnf
在my.cnf(my.ini)添加如下配置:
[mysqld]
sql_mode=’你想要的模式’

MySql常用命令总结

1、使用SHOW语句找出在服务器上当前存在什么数据库:
mysql> SHOW DATABASES;

2、创建一个数据库MYSQLDATA
mysql> CREATE DATABASE MYSQLDATA;

3:选择你所创建的数据库
mysql> USE MYSQLDATA; (按回车键出现Database changed 时说明操作成功!)

4:查看现在的数据库中存在什么表
mysql> SHOW TABLES;

5:创建一个数据库表
mysql> CREATE TABLE MYTABLE (name VARCHAR(20), sex CHAR(1));

6:显示表的结构:
mysql> DESCRIBE MYTABLE;

7:往表中加入记录
mysql> insert into MYTABLE values (”hyq”,”M”);

8:用文本方式将数据装入数据库表中(例如D:/mysql.txt)
mysql> LOAD DATA LOCAL INFILE “D:/mysql.txt” INTO TABLE MYTABLE;

9:导入.sql文件命令(例如D:/mysql.sql)
mysql>use database;
mysql>source d:/mysql.sql;

10:删除表
mysql>drop TABLE MYTABLE;

11:清空表
mysql>delete from MYTABLE;

12:更新表中数据
mysql>update MYTABLE set sex=”f” where name=’hyq’;

以下是无意中在网络看到的使用MySql的管理心得,
在windows中MySql以服务形式存在,在使用前应确保此服务已经启动,未启动可用net start mysql命令启动。而Linux中启动时可用“/etc/rc.d/init.d/mysqld start”命令,注意启动者应具有管理员权限。
刚安装好的MySql包含一个含空密码的root帐户和一个匿名帐户,这是很大的安全隐患,对于一些重要的应用我们应将安全性尽可能提高,在这里应把匿名帐户删除、 root帐户设置密码,可用如下命令进行:
use mysql;
delete from User where User=””;
update User set Password=PASSWORD(’newpassword’) where User=’root’;
如果要对用户所用的登录终端进行限制,可以更新User表中相应用户的Host字段,在进行了以上更改后应重新启动数据库服务,此时登录时可用如下类似命令:
mysql -uroot -p;
mysql -uroot -pnewpassword;
mysql mydb -uroot -p;
mysql mydb -uroot -pnewpassword;
上面命令参数是常用参数的一部分,详细情况可参考文档。此处的mydb是要登录的数据库的名称。
在 进行开发和实际应用中,用户不应该只用root用户进行连接数据库,虽然使用root用户进行测试时很方便,但会给系统带来重大安全隐患,也不利于管理技 术的提高。我们给一个应用中使用的用户赋予最恰当的数据库权限。如一个只进行数据插入的用户不应赋予其删除数据的权限。MySql的用户管理是通过 User表来实现的,添加新用户常用的方法有两个,一是在User表插入相应的数据行,同时设置相应的权限;二是通过GRANT命令创建具有某种权限的用 户。其中GRANT的常用用法如下:
grant all on mydb.* to NewUserName@HostName identified by “password” ;
grant usage on *.* to NewUserName@HostName identified by “password”;
grant select,insert,update on mydb.* to NewUserName@HostName identified by “password”;
grant update,delete on mydb.TestTable to NewUserName@HostName identified by “password”;
若 要给此用户赋予他在相应对象上的权限的管理能力,可在GRANT后面添加WITH GRANT OPTION选项。而对于用插入User表添加的用户,Password字段应用PASSWORD 函数进行更新加密,以防不轨之人窃看密码。对于那些已经不用的用户应给予清除,权限过界的用户应及时回收权限,回收权限可以通过更新User表相应字段, 也可以使用REVOKE操作。
下面给出本人从其它资料(www.cn-java.com)获得的对常用权限的解释:
全局管理权限:
FILE: 在MySQL服务器上读写文件。
PROCESS: 显示或杀死属于其它用户的服务线程。
RELOAD: 重载访问控制表,刷新日志等。
SHUTDOWN: 关闭MySQL服务。
数据库/数据表/数据列权限:
ALTER: 修改已存在的数据表(例如增加/删除列)和索引。
CREATE: 建立新的数据库或数据表。
DELETE: 删除表的记录。
DROP: 删除数据表或数据库。
INDEX: 建立或删除索引。
INSERT: 增加表的记录。
SELECT: 显示/搜索表的记录。
UPDATE: 修改表中已存在的记录。
特别的权限:
ALL: 允许做任何事(和root一样)。
USAGE: 只允许登录–其它什么也不允许做。

mysql联合索引 sql索引使用

注意:Index(Name,Age)表示在Name,Age两列上建立联合索引

由于索引对数据库的查询性能有着至关重要的影响,下面是我的一些总结和体会:

一个查询一次只能使用一个索引:select name from user where name=’plantegg’ and age>35 , 如果Index(name); Index(age)的话,MySQL查询优化器会自动选择一个索引来使用;
MySQL选择哪个索引,可以这样来看:mysql> show index from photo;
+——-+————+————————+————–+—————+———–+————-+———-+——–+——+————+———+
| Table | Non_unique | Key_name               | Seq_in_index | Column_name   | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+——-+————+————————+————–+—————+———–+————-+———-+——–+——+————+———+
| photo |           0 | PRIMARY                 |             1 | photo_id       | A         |       237871 |     NULL | NULL   |       | BTREE       |         |
| photo |           1 | index_random           |             1 | random         | A         |       237871 |     NULL | NULL   | YES   | BTREE       |         |
| photo |           1 | FK_photo_profile_id     |             1 | profile_id     | A         |       237871 |     NULL | NULL   |       | BTREE       |         |
| photo |           1 | FK_photo_temp_photo_id |             1 | temp_photo_id | A         |       237871 |     NULL | NULL   | YES   | BTREE       |         |
| photo |           1 | FK_photo_album_id       |             1 | album_id       | A         |       237871 |     NULL | NULL   | YES   | BTREE       |         |
+——-+————+————————+————–+—————+———–+————-+———-+——–+——+————+———+
Cardinality越大表示索引候选分得越细(默认都是BTree索引);
你也可以试试Force Index强制使用某个索引看看速度是不是MySQL是不是查询起来更快(如果真是这样的话你需要Analyze yourTable 了,MySQL重新计算你的Cardinality以帮助他正确地选择INDEX)
仔细分析Explain的结果:重点留意Extra,Key,Rows,Select_type的结果!
小心查询中的Group by 、order by之类的,基本上这样的查询在Explain的时候都会出现: Using where; Using temporary; Using filesort
联 合索引要小心使用,Index(Name,Age)时,如果where name=’pp’ 能使用索引,where age=25时不能使用索引;where name=’pp’ and age>25 能使用索引;     where name =’pp’   order by   age   能使用索引;   where   name>’pp’   order by age   不能使用索引,但是 where   name>’pp’   order by name,age   能使用索引,请仔细留意差异   ;   order by name asc age desc 将不能使用索引!
索引只有被加入到内存里的时候对你的查询才有帮助,如果索引太大根本无法放入内存这样的索引失去了意义!访问索引的时候还需要Random   Aceess   Disk这比不用索引还慢!
select   的 时候能不用select * 就不要用,也就是需要哪些列只拿那些列(Hibernate那些对性能没有啥好处的),比如:在Index(Name)的时候,select * from user where name like ‘pp%’ 和 select name from user where name like ‘pp%’ 两者性能千差万别,如果有10000条符合记录的结果的话(User表总共有10亿条记录)前一个查询可能需要2分钟(假设你的系统每秒100 IOPS的样子)后一个查询可能只需要0.01秒!因为前一个查询要从硬盘上取出散布在到处的这10000条记录,后一个查询直接从内存中的索引上拿 Name就够了!后一个查询你explain的时候在Extra中会看到Using Index。

永远要警惕对磁盘的随机访问,顺序读写 和随机访问的性能差别是N个数量级的(顺序读写的时候你的OS、Dish Cache 这个时候大显身手)对这个问题如果感兴趣的话建议你去用C写个测试程序,随机读写的时候不断地fseek,相应地同样的功能你不要fseek而是通过顺序 读写到内存中,在内存自己扔掉那些应该由磁盘去fseek的地方,应该明白我的意思吧!
5.0.27后,MYSQL就支持set profling=1了,这样可以详细分析你的SQL语句每一步骤的时间消耗了
如果order by 的时候有 limit + 索引配合的话,你会有意外惊喜的

分享网站群发站内信数据库表设计

“站内信”不同于电子邮件,电子邮件通过专门的邮件服务器发送、保存。而“站内信”是系统内的消息,说白了,“站内信”的实现,就是通过数据库插入记录来实现的。
“站内信”有两个基本功能。一:点到点的消息传送。用户给用户发送站内信;管理员给用户发送站内信。二:点到面的消息传送。管理员给用户(指定满足某一 条件的用户群)群发消息。点到点的消息传送很容易实现,本文不再详述。下面将根据不同的情况,来说说“站内信”的群发是如何实现的。

第一种情况,站内的用户是少量级别的。(几十到上百)

这种情况,由于用户的数量非常少,因此,没有必要过多的考虑数据库的优化,采用简单的表格,对系统的设计也来的简单,后期也比较容易维护,是典型的用空间换时间的做法。

数据库的设计如下:表名:Message

ID:编号;SendID:发送者编号;RecID:接受者编号(如为0,则接受者为所有人);Message:站内信内容;Statue:站内信的查看状态;PDate:站内信发送时间;

如果,某一个管理员要给所有人发站内信,则先遍历用户表,再按照用户表中的所有用户依次将站内信插入到Message表中。这样,如果有56个用户,则群发一条站内信要执行56个插入操作。这个理解上比较简单,比较耗损空间。

某一个用户登陆后,查看站内信的语句则为:

Select * FROM Message Where RecID=‘ID’ OR RecID=0

第二种情况,站内的用户中量级别的(上千到上万)。

如果还是按照第一种情况的思路。那发一条站内信的后果基本上就是后台崩溃了。因为,发一条站内信,得重复上千个插入记录,这还不是最主要的,关键是上千 乃至上万条记录,Message字段的内容是一样的,而Message有大量的占用存储空间。比方说,Message字段有100个汉字,占用200个字 节,那么5万条,就占用200×50000=10000000个字节=10M。简单的一份站内信,就占用10M,这还让不让人活了。

因此,将原先的表格拆分为两个表,将Message的主体放在一个表内,节省空间的占用

数据库的设计如下:

表名:Message

ID:编号;SendID:发送者编号;RecID:接受者编号(如为0,则接受者为所有人);MessageID:站内信编号;Statue:站内信的查看状态;

表名:MessageText

ID:编号;Message:站内信的内容;PDate:站内信发送时间;

在管理员发一封站内信的时候,执行两步操作。先在MessageText表中,插入站内信的内容。然后在Message表中给所有的用户插入一条记录,标识有一封站内信。

这样的设计,将重复的站内信的主体信息(站内信的内容,发送时间)放在一个表内,大量的节省存储空间。不过,在查询的时候,要比第一种情况来的复杂。

第三种情况,站内的用户是大量级的(上百万),并且活跃的用户只占其中的一部分。

大家都有这样的经历,某日看一个网站比较好,一时心情澎湃,就注册了一个用户。过了一段时间,由于种种原因,就忘记了注册时的用户名和密码,也就不再登陆了。那么这个用户就称为不活跃的。从实际来看,不活跃的用户占着不小的比例。

我们以注册用户2百万,其中活跃用户只占其中的10%。

就算是按照第二种的情况,发一封“站内信”,那得执行2百万个插入操作。但是其中的有效操作只有10%,因为另外的90%的用户可能永远都不会再登陆了。

在这种情况下,我们还得把思路换换。

数据库的设计和第二种情况一样:

表名:Message

ID:编号;SendID:发送者编号;RecID:接受者编号(如为0,则接受者为所有人);MessageID:站内信编号;Statue:站内信的查看状态;

表名:MessageText

ID:编号;Message:站内信的内容;PDate:站内信发送时间;

管理员发站内信的时候,只在MessageText插入站内信的主体内容。Message里不插入记录。

那么,用户在登录以后,首先查询MessageText中的那些没有在Message中有记录的记录,表示是未读的站内信。在查阅站内信的内容时,再将相关的记录插入到Message中。

这个方法和第二种的比较起来。如果,活跃用户是100%。两者效率是一样的。而活跃用户的比例越低,越能体现第三种的优越来。只插入有效的记录,那些不活跃的,就不再占用空间了。

以上,是我对群发“站内信”的实现的想法。

百万级用户量的站内信群发数据库设计

随着WEB2.0的发展,用户之间的信息交互也变得十分庞大,而且实时性要求越来越高。现在很多SNS网站和一部分CMS网站都广泛地应 用了站内信这一模块,这个看似简单的东西其实背后隐藏着很多需要设计师重视的设计细节,要做好这个“邮递员”是很不容易的。为什么这么说呢?下面我们就一 步步来探索设计一个百万级用户量的站内信群发数据库,看完以后你就会明白什么是真正可靠高效的“邮递员”。

1、几十——几百的用户量

这样的网站规模最小,可能是一个中小企业的CMS系统,面对这样的用户量,我们就不必要考虑短消息数据量太大的问题了,所以按照怎么方便怎么来的原 则,群发就每人复制一条消息数据,这样用户可以自己管理自己的消息,可以非常方便进行“已读、未读、删除”等操作。按照这个思路,我们的数据库设计如下:

表T_Message

Id bigint –消息ID
SenderId bigint –发送者ID
ReceiverId bigint –接收者ID
SendTime datetime –发送时间
ReadFlag tinyint –已读标志
MessageText text –消息正文

这样,我们接受自己的消息时只要做如下查询:
SELECT * FROM T_Message WHERE ReceiverId=myid

查询自己的未读消息只要做如下查询:
SELECT * FROM T_Message WHERE ReceiverId=myid and ReadFlag=0

这种方法很简单,可能是我们第一个想到的,对于这样的用户量的情况这样的设计确实也足够了。

2、几千——几万的用户量

用户量到了这样的级哦别,这个网站应该算是比较大了,笔者估计,可能是一个地区性的SNS网站。那么面对这样的用户量,我们又该如何来设计站内信群 发呢?上面第一种思路还行得通吗?应该这样说,如果勉强要用上面那种设计,也是可以的,只不过T_Message可能要考虑分区。但是,大家会不会觉得消 息正文复制那么多条对于这样的用户量来讲空间浪费太大,因为考虑到接收者一般是不修改消息正文的,所以我们可以让所有接收者共享一条消息正文。具体数据库 设计方法和上面大同小异:

T_Message

Id bigint –消息ID
SenderId bigint –发送者ID
ReceiverId bigint –接收者ID
SendTime datetime –发送时间
ReadFlag tinyint –已读标志
MessageTextId bigint –这里把消息正文内容换成消息正文Id

T_MessageText

Id bigint –ID标识
SenderId bigint –发送者ID
MessageText text –消息正文
这样,我们就大大节省了消息的存储空间,但是查询的时候就稍微麻烦一点,就需要进行联合查询了,查询自己的未读消息可以这样(意思一下,可能还有更高效的查询方式):

SELECT T_Message.*,T_MessageText.* FROM T_Message
INNER JOIN T_MessageText ON T_Message.MessageTextId=T_MessageText.Id
WHERE T_Message.ReceiverId=myid AND T_Message.ReadFlag=0
用这种方法除了正文我们不能随便删除外,用户还是可以自己管理自己的消息。

3、百万级大用户量

如果一个网站到了百万级的用户量了,那我不得不膜拜该网站和网站经营者了,因为经营这样的网站一直是笔者的梦想:)好了,回归正题,如果这样的系统 放你面前,让你设计一个站内信群发数据库,你该何去何从,总之,上面两种常规的办法肯定是行不通了的,因为庞大的数据量会让消息表撑爆,即使你分区也无济 于事。这时候作为一个系统架构师的你,可能不仅仅要从技术的角度去考虑这个问题,更要从用户实际情况去着手寻找解决问题的办法。这里,有一个概念叫“活跃 用户”,即经常登录网站的用户,相对于那些一时冲动注册而接下来又从来不登录的用户来说,活跃用户对网站的忠诚度很高,从商业的角度来讲,忠诚的客户享受 更高端的服务。

根据这个思路,我们来探索一种方法。假设网站有500万注册用户,其中活跃用户为60万(这个比例真很不错了),现在我们要对所有用户群发一封致谢信。还是上面两张表,首先我们可以先往消息表中插入一条群发标识为-1的 消息,这里我们用字段SourceMessageId(原始消息)来标识(-1为原始群发消息本身,其他则是原始消息id),这样其实群发的工作已经完成 了,用户可以看到这条公共的消息了。但是用户需要有消息的控制权,所以必须让每个用户拥有一条自己的消息。要达到这个目的,我们可以让用户登录时检查是否 已经拷贝原始消息,如果没有拷贝,则拷贝一份原始消息并插入消息表,群发标识为原始消息的id;如果已经存在原始消息的拷贝,则什么都不做。这样,我们就只要为这60万活跃用户消耗消息空间就可以了。具体数据库设计如下:

T_Message

Id bigint –消息ID
SenderId bigint –发送者ID
ReceiverId bigint –接收者ID,如果为原始群发消息则为-1
SendTime datetime –发送时间
ReadFlag tinyint –已读标志,如果为原始群发消息则统一为0未读
SourceMessageId bigint

MySQL CAST与CONVERT 函数的用法

MySQL 的CAST()和CONVERT()函数可用来获取一个类型的值,并产生另一个类型的值。两者具体的语法如下:

CAST(value as type);
CONVERT(value, type);
就是CAST(xxx AS 类型), CONVERT(xxx,类型)。

可以转换的类型是有限制的。这个类型可以是以下值其中的一个:

二进制,同带binary前缀的效果 : BINARY
字符型,可带参数 : CHAR()
日期 : DATE
时间: TIME
日期时间型 : DATETIME
浮点数 : DECIMAL
整数 : SIGNED
无符号整数 : UNSIGNED

下面举几个例子:

例一
 
mysql> SELECT CONVERT('23',SIGNED);
    +----------------------+
    | CONVERT('23',SIGNED) |
    +----------------------+
    |                   23 |
    +----------------------+
    1 row in set
例二
 
mysql> SELECT CAST('125e342.83' AS signed);
    +------------------------------+
    | CAST('125e342.83' AS signed) |
    +------------------------------+
    |                          125 |
    +------------------------------+
    1 row in set
例三
 
mysql> SELECT CAST('3.35' AS signed);
    +------------------------+
    | CAST('3.35' AS signed) |
    +------------------------+
    |                      3 |
    +------------------------+
    1 row in set
像上面例子一样,将varchar 转为int 用 cast(a as signed),其中a为varchar类型的字符串。

例4

在SQL Server中,下面的代码演示了datetime变量中,仅包含单纯的日期和单纯的时间时,日期存储的十六进制存储表示结果。
 
DECLARE @dt datetime
    --单纯的日期
    SET @dt='1900-1-2'
    SELECT CAST(@dt as binary(8))
    --结果: 0x0000000100000000
      
    --单纯的时间
    SET @dt='00:00:01'
    SELECT CAST(@dt as binary(8))
    --结果: 0x000000000000012C
MySQL的类型转换和SQL Server一样,就是类型参数有点点不同:CAST(xxx AS 类型) , CONVERT(xxx,类型)。