JavaEx博客广场

DATE_FORMAT(create_time, '%Y-%m-%d %H:%i:%s') AS create_time
以下记录修改mysql时区的几种方法。具体:方法一:通过mysql命令行模式下动态修改1.1 查看mysql当前时间,当前时区 select curtime(); #或select now()也可以+-----------+| curtime() |+-----------+| 15:18:10 |+-----------+ show variables like "%time_zone%";+------------------+--------+| Variable_name | Value |+------------------+--------+| system_time_zone | CST || time_zone | SYSTEM |+------------------+--------+2 rows in set (0.00 sec)#time_zone说明mysql使用system的时区,system_time_zone说明system使用CST时区 1.2 修改时区 set global time_zone = '+8:00'; ##修改mysql全局时区为北京时间,即我们所在的东8区 set time_zone = '+8:00'; ##修改当前会话时区 flush privileges; #立即生效 方法二:通过修改my.cnf配置文件来修改时区# vim /etc/my.cnf ##在[mysqld]区域中加上default-time_zone = '+8:00'# /etc/init.d/mysqld restart ##重启mysql使新时区生效 方法三:如果不方便重启mysql,又想临时解决时区问题,可以通过php或其他语言在初始化mysql时初始化mysql时区
mysqlCONCAT('doc/', dti.id, '/', dmi.id) AS hrefAND CONCAT(',', tag, ',') LIKE '%,1,%'sql serverAND ','+tag+',' LIKE '%,1,%'
mysqlCreate Table user_info( id INT primary key auto_increment);sql serverCreate Table user_info ( id int identity(1, 1) primary key);
分布式系统的CAP理论理论首先把分布式系统中的三个特性进行了如下归纳一致性(Consistency):在分布式系统中的所有数据备份,在同一时刻是否同样的值。(所有节点在同一时间具有相同的数据)可用性(Availability):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(保证每个请求不管成功或者失败都有响应)分区容错性(Partition tolerance):以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。(系统中任意信息的丢失或失败不会影响系统的继续运作)CAP理论的核心一个分布式系统不可能同时很好的满足一致性、可用性和分区容错性这三个需求最多只能同时较好地满足两个而由于当前的网络硬件肯定会出现延迟、丢包等现象,所以:分区容忍性是我们必须要实现的NoSQL 数据库三大类根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三大类 CA 单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大 CP 满足一致性,分区容忍性的系统,通常性能不是特别高 AP 满足可用性,分区容忍性的系统,通常可能对一致性要求低一些
水平拆分水平拆分是指数据表行的拆分,表的行数超过200万行时,就会变慢,这时可以把一张的表的数据拆成多张表来存放通常情况下,我们使用取模的方式来进行表的拆分比如一张有400万的用户表user_info,为提高其查询效率我们把其分成4张表user_info1、user_info2、user_info3、user_info4通过用 id 取模的方法把数据分散到四张表内 id%4 + 1 = [1,2,3,4]然后查询、更新、删除也是通过取模的方法来查询举例说明QQ的登录表假设QQ的用户有100亿,如果只有一张表,每个用户登录的时候数据库都要从这100亿中查找,会很慢很慢如果将这一张表分成100份,每张表有1亿条,就小了很多,比如qq0、qq1、qq2…qq99表用户登录的时候,可以将用户的 id%100,那么会得到0-99的数,查询表的时候,将表名qq跟取模的数连接起来,就构建了表名比如123456789用户,取模的89,那么就到qq89表查询,查询的时间将会大大缩短水平拆分的优点表关联基本能够在数据库端全部完成不会存在某些超大型数据量和高负载的表遇到瓶颈的问题应用程序端整体架构改动相对较少事务处理相对简单只要切分规则能够定义好,基本上较难遇到扩展性限制水平切分的缺点切分规则相对更为复杂,很难抽象出一个能够满足整个数据库的切分规则后期数据的维护难度有所增加,人为手工定位数据更困难应用系统各模块耦合度较高,可能会对后面数据的迁移拆分造成一定的困难垂直拆分垂直拆分是指数据表列的拆分,把一张列比较多的表拆分为多张表表的记录并不多,但是字段却很长,表占用空间很大,检索表的时候需要执行大量的IO,严重降低了性能这时需要把大的字段拆分到另一个表,并且该表与原表是一对一的关系通常我们按以下原则进行垂直拆分把不常用的字段单独放在一张表把text,blob等大字段拆分出来放在附表中经常组合查询的列放在一张表中举例说明学生答题表student_answer有如下字段id name score 题目 回答其中题目和回答是比较大的字段,id name score比较小如果我们只想查询id为8的学生的分数SELECT score FROM student_answer WHERE id='8';虽然只是查询分数,但是题目和回答这两个大字段也是要被扫描的,很消耗性能但是我们只关心分数,并不想查询题目和回答。这就可以使用垂直分割我们可以把题目单独放到一张表中,通过id与student_answer表建立一对一的关系同样将回答单独放到一张表中。这样我们插入student_answer中的分数的时候就不会扫描题目和回答了垂直切分的优点数据库的拆分简单明了,拆分规则明确应用程序模块清晰明确,整合容易数据维护方便易行,容易定位垂直切分的缺点部分表关联无法在数据库级别完成,需要在程序中完成对于访问极其频繁且数据量超大的表仍然存在性能平静,不一定能满足要求事务处理相对更为复杂切分达到一定程度之后,扩展性会遇到限制过度切分可能会使系统太复杂而难以维护数据库拆分原则优先考虑缓存降低对数据库的读操作再考虑读写分离,降低数据库写操作最后开始数据拆分,切分模式:首先垂直拆分、再次水平拆分首先考虑按照业务垂直拆分再考虑水平拆分:先分库(设置数据路由规则,把数据分配到不同的库中)最后再考虑分表,单表拆分到数据1000万以内
回到顶部