select count(*) from sometable where datetimecolumn=UNIX_TIMESTAMP('2010-03-01 00:00:00') and
岳普湖ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为创新互联的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：13518219792（备注：SSL证书合作）期待与您的合作！
datetimecolumnUNIX_TIMESTAMP('2010-03-02 00:00:00')，也可以在调用程序中先转换为UNIX时间再传入MySql，总之这种方式有利于快速查询时间段，不过显示时间则需要再反转一次。
Mysql中经常用来存储日期的数据类型有三种：Date、Datetime、Timestamp。
Date数据类型：用来存储没有时间的日期。Mysql获取和显示这个类型的格式为“YYYY-MM-DD”。支持的时间范围为“1000-00-00”到“9999-12-31”。
Datetime类型：存储既有日期又有时间的数据。存储和显示的格式为 “YYYY-MM-DD HH:MM:SS”。支持的时间范围是“1000-00-00 00:00:00”到“9999-12-31 23:59:59”。
Timestamp类型：也是存储既有日期又有时间的数据。存储和显示的格式跟Datetime一样。支持的时间范围是“1970-01-01 00:00:01”到“2038-01-19 03:14:07”。
所有不符合上面所述格式的数据都会被转换为相应类型的0值。（0000-00-00或者0000-00-00 00:00:00）
术式之后皆为逻辑，一切皆为需求和实现。希望此文能从需求、现状和解决方式的角度帮大家理解隔离级别。
隔离级别的产生
在串型执行的条件下，数据修改的顺序是固定的、可预期的结果，但是并发执行的情况下，数据的修改是不可预期的，也不固定，为了实现数据修改在并发执行的情况下得到一个固定、可预期的结果，由此产生了隔离级别。
所以隔离级别的作用是用来平衡数据库并发访问与数据一致性的方法。
事务的4种隔离级别
READ UNCOMMITTED 未提交读，可以读取未提交的数据。READ COMMITTED 已提交读，对于锁定读(select with for update 或者 for share)、update 和 delete 语句， InnoDB 仅锁定索引记录，而不锁定它们之间的间隙，因此允许在锁定的记录旁边自由插入新记录。 Gap locking 仅用于外键约束检查和重复键检查。REPEATABLE READ 可重复读，事务中的一致性读取读取的是事务第一次读取所建立的快照。SERIALIZABLE 序列化
在了解了 4 种隔离级别的需求后，在采用锁控制隔离级别的基础上，我们需要了解加锁的对象(数据本身间隙)，以及了解整个数据范围的全集组成。
数据范围全集组成
SQL 语句根据条件判断不需要扫描的数据范围（不加锁）；
SQL 语句根据条件扫描到的可能需要加锁的数据范围；
以单个数据范围为例，数据范围全集包含：（数据范围不一定是连续的值，也可能是间隔的值组成）
1. 数据已经填充了整个数据范围：（被完全填充的数据范围，不存在数据间隙）
整形，对值具有唯一约束条件的数据范围 1～5 ，
已有数据1、2、3、4、5，此时数据范围已被完全填充；
整形，对值具有唯一约束条件的数据范围 1 和 5 ，
已有数据1、5，此时数据范围已被完全填充；
2. 数据填充了部分数据范围：（未被完全填充的数据范围，是存在数据间隙）
整形的数据范围 1～5 ，
已有数据 1、2、3、4、5，但是因为没有唯一约束，
所以数据范围可以继续被 1～5 的数据重复填充；
整形，具有唯一约束条件的数据范围 1～5 ，
已有数据 2，5，此时数据范围未被完全填充，还可以填充 1、3、4 ；
3. 数据范围内没有任何数据（存在间隙）
如下：
整形的数据范围 1～5 ，数据范围内当前没有任何数据。
在了解了数据全集的组成后，我们再来看看事务并发时，会带来的问题。
无控制的并发所带来的问题
并发事务如果不加以控制的话会带来一些问题，主要包括以下几种情况。
1. 范围内已有数据更改导致的：
更新丢失：当多个事务选择了同一行，然后基于最初选定的值更新该行时，
由于每个事物不知道其他事务的存在，最后的更新就会覆盖其他事务所做的更新；
脏读： 一个事务正在对一条记录做修改，这个事务完成并提交前，这条记录就处于不一致状态。
这时，另外一个事务也来读取同一条记录，如果不加控制，
第二个事务读取了这些“脏”数据，并据此做了进一步的处理，就会产生提交的数据依赖关系。
这种现象就叫“脏读”。
2. 范围内数据量发生了变化导致：
不可重复读：一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，
却发现其读出的数据已经发生了改变，或者某些记录已经被删除了。
这种现象就叫“不可重复读”。
幻读：一个事务按相同的查询条件重新读取以前检索过的数据，
却发现其他事务插入了满足其查询条件的新数据，这种现象称为“幻读”。
可以简单的认为满足条件的数据量变化了。
因为无控制的并发会带来一系列的问题，这些问题会导致无法满足我们所需要的结果。因此我们需要控制并发，以实现我们所期望的结果(隔离级别)。
MySQL 隔离级别的实现
InnoDB 通过加锁的策略来支持这些隔离级别。
行锁包含：
Record Locks
索引记录锁，索引记录锁始终锁定索引记录，即使表中未定义索引，
这种情况下，InnoDB 创建一个隐藏的聚簇索引，并使用该索引进行记录锁定。
Gap Locks
间隙锁是索引记录之间的间隙上的锁，或者对第一条记录之前或者最后一条记录之后的锁。
间隙锁是性能和并发之间权衡的一部分。
对于无间隙的数据范围不需要间隙锁，因为没有间隙。
Next-Key Locks
索引记录上的记录锁和索引记录之前的 gap lock 的组合。
假设索引包含 10、11、13 和 20。
可能的next-key locks包括以下间隔，其中圆括号表示不包含间隔端点，方括号表示包含端点：
(负无穷大, 10] (10, 11] (11, 13] (13, 20] (20, 正无穷大) 对于最后一个间隔，next-key将会锁定索引中最大值的上方，
左右滑动进行查看
"上确界"伪记录的值高于索引中任何实际值。
上确界不是一个真正的索引记录，因此，实际上，这个 next-key 只锁定最大索引值之后的间隙。
基于此，当获取的数据范围中，数据已填充了所有的数据范围，那么此时是不存在间隙的，也就不需要 gap lock。
对于数据范围内存在间隙的，需要根据隔离级别确认是否对间隙加锁。
默认的 REPEATABLE READ 隔离级别，为了保证可重复读，除了对数据本身加锁以外，还需要对数据间隙加锁。
READ COMMITTED 已提交读，不匹配行的记录锁在 MySQL 评估了 where 条件后释放。
对于 update 语句，InnoDB 执行 "semi-consistent" 读取，这样它会将最新提交的版本返回到 MySQL，
以便 MySQL 可以确定该行是否与 update 的 where 条件相匹配。
总结延展：
唯一索引存在唯一约束，所以变更后的数据若违反了唯一约束的原则，则会失败。
当 where 条件使用二级索引筛选数据时，会对二级索引命中的条目和对应的聚簇索引都加锁；所以其他事务变更命中加锁的聚簇索引时，都会等待锁。
行锁的增加是一行一行增加的，所以可能导致并发情况下死锁的发生。
例如，
在 session A 对符合条件的某聚簇索引加锁时，可能 session B 已持有该聚簇索引的 Record Locks，而 session B 正在等待 session A 已持有的某聚簇索引的 Record Locks。
session A 和 session B 是通过两个不相干的二级索引定位到的聚簇索引。
session A 通过索引 idA，session B通过索引 idB 。
当 where 条件获取的数据无间隙时，无论隔离级别为 rc 或 rr，都不会存在间隙锁。
比如通过唯一索引获取到了已完全填充的数据范围，此时不需要间隙锁。
间隙锁的目的在于阻止数据插入间隙，所以无论是通过 insert 或 update 变更导致的间隙内数据的存在，都会被阻止。
rc 隔离级别模式下，查询和索引扫描将禁用 gap locking，此时 gap locking 仅用于外键约束检查和重复键检查（主要是唯一性检查）。
rr 模式下，为了防止幻读，会加上 Gap Locks。
事务中，SQL 开始则加锁，事务结束才释放锁。
就锁类型而言，应该有优化锁，锁升级等，例如rr模式未使用索引查询的情况下，是否可以直接升级为表锁。
就锁的应用场景而言，在回放场景中，如果确定事务可并发，则可以考虑不加锁，加快回放速度。
锁只是并发控制的一种粒度，只是一个很小的部分：
从不同场景下是否需要控制并发，(已知无交集且有序的数据的变更，MySQL 的 MTS 相同前置事务的多事务并发回放)
并发控制的粒度，(锁是一种逻辑粒度，可能还存在物理层和其他逻辑粒度或方式)
相同粒度下的优化，(锁本身存在优化，如IX、IS类型的优化锁)
粒度加载的安全性能(如获取行锁前，先获取页锁，页锁在执行获取行锁操作后即释放，无论是否获取成功)等多个层次去思考并发这玩意。
linux下配置mysql主从同步的步骤
一、主机环境
主机：
master操作系统：rhel6.0
IP：172.16.0.100
MySQL版本：5.1.47
从机：
slave操作系统：rhel6.0
IP：172.16.0.200
MySQL版本：5.1.47
二、创建数据库
分别登录master机和slave机的mysql：mysql –u root –p
创建数据库：create database repl;
三、master机和slave机的相关配置
1、修改master机器中mysql配置文件my.cnf，该文件在/etc目录下
在[mysqld]配置段添加如下字段
server-id=1
log-bin=mysql-bin
binlog-do-db=repl //需要同步的数据库，如果没有本行，即表示同步所有的数据库
binlog-ignore-db=mysql //被忽略的数据库
在master机上为slave机添加一同步帐号
grant replication slave on *.* to 'replication'@'172.16.0.200' identified by '123456';
重启master机的mysql服务：service mysqld restart
用show master status 命令看日志情况
mysqlshow master status;
+-----------------+------------+-------------------+-----------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-----------------+------------+-------------------+-----------------------+
| log.000003 | 98 | repl | mysql |
+-----------------+------------+-------------------+-----------------------+
1 row in set (0.00 sec)
2、修改slave机中mysql配置文件
同样在[mysqld]字段下添加如下内容
server-id=2
master-host=172.16.0.100
master-user=repl
master-password=123456
master-port=3306
master-connect-retry=60
replicate-do-db=repl //同步的数据库，不写本行 表示 同步所有数据库
然后重启slave机的mysql
在slave机中进入mysql
mysqlstart slave;
mysqlshow slave status\G;
如果Slave_IO_Running、Slave_SQL_Running状态为Yes则表明设置成功。
这时 再执行show slave status\G
显示如下：
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.222
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: log.000003
Read_Master_Log_Pos: 98
Relay_Log_File: mysqld-relay-bin.000002
Relay_Log_Pos: 229
Relay_Master_Log_File: log.000003
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 98
Relay_Log_Space: 229
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
1 row in set (0.00 sec)
Slave_IO_Running: Yes Slave_SQL_Running: Yes
信息中如上两行都为Yes，说明配置成功。
五、测试主从服务器是否能同步
在主服务器上面新建一个表，必须在repl数据下
mysql use repl
Database changed
mysql create table test(id int,name char(10));
Query OK, 0 rows affected (0.00 sec)
mysql insert into test values(1,'zaq');
Query OK, 1 row affected (0.00 sec)
mysql insert into test values(1,'xsw');
Query OK, 1 row affected (0.00 sec)
mysql select * from test;
+------+------+
| id | name |
+-------+------+
| 1 | zaq |
| 1 | xsw |
+-------+------+
2 rows in set (0.00 sec)
在从服务器查看是否同步过来
mysql use repl;
Database changed
mysql select * from test;
+------+------+
| id | name |
+------+------+
| 1 | zaq |
| 1 | xsw |
+------+------+
2 rows in set (0.00 sec)
说明已经配置成功。
四、出现的问题
1. 当在执行start slave这条命令时，系统提示
ERROR 1200 (HY000): The server is not configured as slave; fix in config file or with CHANGE MASTER TO，
执行show slave status;又提示Empty set (0.00 sec)
原因:slave已经默认开启，要先关闭再开启
执行 slave stop;
再执行
change master to master_host='172.16.0.200',master_user='repl',master_password='123456', master_log_file='log.000003' ,master_log_pos=98;
2、出现错误提示 ：Slave_IO_Running:NO
mysql的error日志中信息：
Slave I/O: error connecting to master 'replication@172.16.0.100:3306' - retry-time: 60 retries: 86400, Error_code: 1045
解决方法
1.在主mysql中创建slave远程连接访问时候的登录密码一定要设置对。
2.停止slave上的mysqld服务，从服务器上删除掉所有的二进制日志文件，包括一个数据目录下的master.info文件和hostname-relay-bin开头的文件，然后启动slave上的mysqld服务。
master.info:：记录了Mysql主服务器上的日志文件和记录位置、连接的密码。
3.slave上Slave_SQL_Running: No ，提示某个表定义不正确
解决方法：
清空drop掉master和slave上的已经存在所有表，然后从master库上导入新的数据即可。
执行命令： SET @@auto_increment_increment = 2;
也就是增长幅度为2.
SET @@auto_increment_offset = 1;
就是从1开始增长。
