MySQL怎么存文本不乱码?

导读

MySQL里怎么存储那些看起来会乱码的字符?

我在“UTF8字符集的表怎么直接转UTF8MB4”一文中介绍了如何把表字符集由UTF8直接转换成UTF8MB4的几种方法。

1、只修改字符集(使用默认校验集)

2、同时修改表字符集和校验集

3、只修改某列的字符集

4、同时修改某列的字符集和校验集

好了,有个字符集为UTF8MB4的表中想存储各类不同字符集的文本,有哪些注意事项亿避免乱码?

如果是通过WEB接口存储数据,则建议在browser端、server端全都采用UTF8字符集,MySQL Server端采用UTF8/UTF8MB4均可(针对大多数文本,其实UTF8字符集就足够存储的了)。

其中,MySQL端的字符集设置比较让人头大,涉及到的字符集有好几个:

  • character_set_server,server端默认字符集;

  • character_set_database,database默认字符集,若未设定,则和 character_set_server 的设定一样;database中的 数据表/stored procedure/stored function 也可以自行设定字符集,若未指定,则和 character_set_database 的设置一样;数据表中的字符类型列,也可以单独设定字符集,若未设定,则和该表指定的字符集一样;

  • character_set_client,客户端显示读取结果的字符集;

  • character_set_connection,客户端从server端读取数据时传输字符集;

  • character_set_results,server端将数据发送给客户端时的字符集;

可见,涉及到字符集的因素实在太多,因此我们强烈建议各个环节全部采用同一种字符集,避免出现意外状况。

MySQL采用UTF8MB4字符集时,存储文本实际消耗字节数是由文本内容的字节数决定的,并非总是需要4字节,列举几种情况:

  • 输入字符集任意,且存储ASCII字符时,每个字符需要1byte;

  • 输入字符集是GB2312,且存储的字符是汉字时,每个字符需要2bytes;

  • 输入字符集是UTF8/UTF8MB4,且存储的字符是低编码汉字时,每个字符需要3bytes;

  • 输入字符集是UTF8/UTF8MB4,且存储的字符是高编码汉字时,每个字符需要4bytes;

  • 输入字符集是binary,且存储的字符是高编码汉字时,每个字符需要4bytes;

总结建议

  1. 从前端到后端(浏览器=>WEB Server=>MySQL连接层=>Server层=>DB层>TABLE层),尽可能使用同一种字符集;

  2. 尽可能采用大字符集,也就是优先级:UTF8Mb4 > UTF8 > GBK > LATIN1;

  3. 采用逻辑备份数据时,切记要不定期进行恢复测试,我以前在这方面栽过一次,教训惨痛。

附1,关于编码简介

  • ASCII码,占7bit,由128个字符组成,包括大小写字母、数字0-9、标点符号、非打印字符(换行符、制表符等4个)以及控制字符(退格、响铃等)组成;

  • latin1,占1byte,在ASCII基础上,增加128 ~ 255区间的字符;

  • GB2312等CJK字符集,可变长字符集,最多占2bytes,用于存储常见的CJK字符;

  • UTF8,可变长字符集,最多占3bytes,可以囊括ASCII、CJK及其他绝大多数常用语言文字;这中间其实还有个UNICODE字符集,它也是2bytes的,也能囊括ASCII字符,但即便是ASCII字符也需要消耗2bytes,存在一定浪费,而用UTF8存储ASCII字符时,实际只需要1byte,更为节省存储空间;

  • UTF8MB4,可变长字符集,最多占4bytes,可以包含上面其他几种字符集;同样地,以UTF8MB4存储ASCII字符时,实际上也是只占用1bytes,存储一般的汉字占用3bytes,而存储个别汉字则需要4bytes,存储emoji也至少需要4bytes;

UTF8字符集的表怎么直接转UTF8MB4?

解读

utf8是utf8mb4的子集,一般情况下,应该是可以直接修改表字符集的。

修改字符集的几种方法

方法一

  • 修改表默认字符集

  • 随后再修改所有字符型列的字符集

方法二

也是执行ALTER TABLE来修改,但有更简单的解法

备注
上面两种方法,其实是有区别的。

  • 采用方法一,如果遇到某个列字符集转换完后字节数超限了,会提示错误。

  • 而采用方法二,如果遇到某个列字符集转换完后字节数超限了,则会将这个列数据类型转换成可以容纳更大长度的类型,比如从 TEXT 转成 LONGTEXT 等。

方法三

如果不放心,可以用mysqldump逻辑备份方式,用utf8mb4字符集把数据备份出来,新建表,恢复回去,应该也可以的。

结论

想从小字节数(2字节/3字节)字符集(gb2312、utf8)转换到大字节数(4字节)字符集(utf8mb4),是可以直接转换的。
相反,想从大字节数字符集转成小的,则会有风险,例如字符串被截断等。

案例测试

可以看到,是可以直接转换的。

当然了,生产环境中,如果也想这么做,最好还是先在测试环境进行更严格的测试演练,确保无误后再实施。

参考

  • https://dev.mysql.com/doc/refman/5.7/en/alter-table.html#alter-table-character-set
  • https://dev.mysql.com/doc/refman/5.7/en/charset-unicode-conversion.html
  • http://imysql.com/2013/11/19/problem-about-mysql-date-function-charset.shtml
  • http://imysql.com/2013/10/29/misunderstand-about-charset-handshake.shtml
  • http://imysql.com/charset_tips
  • http://imysql.com/2007_12_16_mysql_faq_how_to_change_default_charset
  • http://imysql.com/2007_12_23_mysql_faq_how_to_set_default_table_charset
  • http://imysql.com/2007_12_25_mysql_faq_how_to_set_default_field_charset
  • http://imysql.com/node/733

MySQL误删数据救命指南

导读

别再因为误删数据让快到手的年终奖给飞了啊,亲们~

请原谅我又标题党了一次,其实并非救命指南,顶多算预防手册。

事情缘起有次上课,大家聊起亲手造了啥大故障,排名最前的几种是:

  • 误删文件。

  • 误删库、表。

  • 错误全表删除 / 更新。

  • 升级操作失误。

都来看看你命中过几个,hoho。

简单说下我亲手造的一个大事故吧。

那大概是一个春暖花开的季节,我的内心是激动澎湃的,因为已经安排了休假计划。在这前几天,已经把一个新项目的数据库环境都部署好了,包括自动化备份。

等我美美的出去玩的时候,悲剧发生了,业务要求进行数据回滚,但发现备份文件不可用,原因是 备份时指定的字符集和表字符集不一致。我勒个擦,原来该项目采用新的字符集,但是我没有认真检查确认并修改备份脚本,结果导致备份失效。最后,因为这个事,当季度绩效结果被降档,boss也为此背锅~

好吧,回到正题,先说几点我平时预防误操作导致文件/数据丢失不成熟的建议:

  1. 欲删除文件时,将rm命令改成mv,可在系统层面将rm命令做个alias(或参考Windows / Mac OSX做法,删除文件时先进回收站)。

  2. 删除数据库、表时,不要用drop命令,而是rename到一个专用归档库里;

  3. 删除表中数据时,不要直接用delete或truncate命令,尤其是truncate命令,目前不支持事务,无法回滚。

  4. 用delete命令删除数据时,应当先显式开启事务,这样误操作时,还有机会进行回滚。

  5. 要大批量删除数据时,可以将这些数据insert…select到一个新表,确认无误后再删除。或者反其道行之,把要保留的数据写到新表,然后将表重命名对掉。

  6. 执行重要命令之前,先准备好相关命令,再三确认无误才之行,对于新鸟而言,最好请你的boss坐你旁边镇场几次,否则极有可能会连累大家~

以上几条,也是我自己奉行的原则。总之,要时刻保持对线上生产环境的敬畏之心。虽说现在大部分操作可以靠平台来完成了,但平台也不是万能的,不也发生过平台本身的缺陷造成数据丢失、代码回滚、部署失误等事故嘛,我就不点名了。

做好备份,不管是物理备份还是逻辑备份!

做好备份,不管是物理备份还是逻辑备份!

做好备份,不管是物理备份还是逻辑备份!

重要的事情说三遍都不嫌多。

说完预防措施,我们再说万一发生误操作时,怎么以最快速度进行补救。 我们分别列举几种常见的情况:

  1. 执行DROP DATABASE / DROP TABLE命令误删库表,如果碰巧采用共享表空间模式的话,还有恢复的机会。如果没有,请直接从备份文件恢复吧。神马,你连备份文件都没有?那麻烦退出DBA届吧,一个连备份都懒得做的人,不配成为DBA的。

  2. 接上,采用共享表空间模式下,误删后立刻杀掉(kill -9)mysql相关进程(mysqld_safe、mysqld),然后尝试从ibdataX文件中恢复数据。

  3. 误删除正在运行中的MySQL表ibd或ibdataX文件。请立即申请对该实例进行维护,当然,不是指把实例关闭,而是把业务暂停,或者把该实例从线上环境摘除,不再写入新数据,然后利用linux系统的proc文件特点,把该ibd文件从内存中拷出来,再进行恢复,因为此时mysqld实例在内存中是保持打开该文件的,切记这时不要把mysqld实例关闭了。

  4. 接上,把复制出来的ibdataX或ibd文件拷贝回datadir后,重启mysqld进入recovery模式,innodb_force_recovery 选项从 0 – 6 逐级测试,直至能备份出(整个实例或单表的)所有数据后,再重建实例(或单表),恢复数据。

  5. 未开启事务模式下,执行delete误删数据。意识到后立即将mysqld(以及mysqld_safe)进程杀掉(kill -9),不要任何犹豫,然后再用工具将表空间数据读取出来。因为执行delete删除后,实际数据并没被物理清除,只是先打上deleted-mark标签,后续再统一清理,因此还有时间差。

  6. 执行truncate误清整表。如果没使用共享表空间模式的话,基本别想了,走备份恢复+binlog吧。

  7. 执行不带where条件的update,或者update错数据。也别费劲了,走备份恢复+binlog吧。

好了,上面列举了几种比较常见的误操作恶劣行径,希望大家都绕着走,不要撸太多,免得手软误操作,或者来知数堂报个班,跟小伙伴一起飞升上神,就再也不担心误操作了,hoho~

禁止修改varchar到int|[运维规范]

在MySQL更改数据类型前一定要特别小心,分析一下是不是可行,另外在更改前,需要先进行备份,备份,备份!!!

一、环境描述

表结构:

写入数据:

确认数据无误:

二、溢出

修改数类型:

查看警告:

到这里实质就可以宣布,死定了。数据已溢出。

查看数据:

这里真是的男人哭吧,哭吧, … 如果是线上环境,想死的心估计大家都有了,不是简单的哭了。如果没有备份,这么重要一例数据没了,有可能意为着项目也有可能受到严重的影响。

这时也不要心存幻想在改回去就好,来看一下操作,请死心!!!

三、结论

  • 生产环境更数据类型明确提出: 不允许varchar 改成int.

  • 更改数据前一定要做好备份,无论是update,delete,或是数据类型更改。

四、操作Tips: 如保备份一列数据?

select pk , 修改的列 from tb where 条件 ;
用命令行记录也可以,用outfile处理也行。

恢复可以用awk反向生成update语句: cat bak.txt |awk ‘{print “update tb set 修改列名=“ $2,”where pk=”$1″;”}

大概这样生成,再执行恢复即可。

数据库的七种武器

作者:赵飞祥(微信号:zhaofx524175360)

现在竞技世界从事数据库相关工作, Oracle 10G OCP,11G OCM,Oracle YEP年轻专家,8年数据库运维和架构经验,对MySQL、Oracle、PostgreSQL、Greenplum、MongoDB等多种常见数据库有丰富的运维实践经验,掌握与数据库相关的前后端架构和DevOps实现技术,擅长数据库架构设计、维护优化、数据流转、Shell和Python开发;乐于技术交流,以网名 yumushui 进行了大量的技术总结和思考分享。

数据库的七种武器,是我在工作维护和接触到的七种常用数据库,包括4种常用的关系型数据库,3种常用nosql数据库。

这些数据库作为业务底层的存储选型,每种数据库都有各自的定位和特点,结合业务,有各自的适用场景,在具体使用和运维时,也有一些特别的注意点。

本文按照顺序依次对这“七种武器”,进行介绍和总结,希望能够帮助大家理清每种“武器”的特点和用法,在合适的场景,使用合适的武器,构建好自己的数据存储体系。

第一种武器:MySQL数据库

1、定位:开源、多平台、关系型数据库
目前使用最广泛、流行度最高的的开源数据库。

2、特点:
功能:支持事务,符合关系型数据库原理,符合ACID,支持多数SQL规范,以二维表方式组织数据,有插件式存储引擎,支持多种存储引擎格式

部署:用编译安装的方式,或者二进制包的方式,按照“安装软件-创建实例-库表用户初始化”,可以很快完成数据库部署

使用:使用标准的SQL语句进行数据库管理,简单SQL语句的并发和性能较好,对视图、存储过程、函数、触发器等支持的不是太好

监控:在命令行界面有一些常用的命令显示状态和性能,在图形界面方面,有比较多的开源监控工具来监控和记录数据库的状态,比如zabbix,nagios,cacti,lepus等

备份:逻辑备份 mysqldump/mysqldumper ,物理备份 用xtrabackup等工具进行备份;

高可用:MySQL高可用有多种方案,官方有基础的master-slave主从复制,新版本的innodb cluster,第三方的有MHA等高可用方案;

扩展:MySQL水平拆分,可以通过水平拆分proxy中间进行逻辑映射和拆分,扩大MySQL数据库的并发能力和吞吐量。

3、适用场景:
默认的innodb存储引擎,支持高并发,简单的绝大部分OLTP场景;

Tokudb存储引擎,使用高并发insert的场景;

Inforbright存储引擎,可以进行列压缩和OLAP统计查询场景;

4、选择注意:
使用MySQL进行OLTP业务时,需要注意数据量级,如果数据量级过大,需要进行水平拆分;

如果有OLAP需求,可以结合其他架构综合考虑。

第二种武器:SQL Server数据库

1、定位:商业、Windows平台、关系型数据库
最早接触、与微软体系结合紧密的的商业数据库,属于“微软技术体系”

2、特点:
功能:支持事务,符合关系型数据库原理,符合ACID,支持多数SQL规范,以二维表方式组织数据

部署:在Windows平台,用图形界面进行软件安装;

使用:在Windows平台,使用SQL Server Mangement Studio图形界面进行安装;

监控:一般通过Windows资源管理和SQL server图形工具进行系统和数据库性能显示;

备份:通常用第三方备份恢复软件进行备份恢复;

高可用:通过共享存储和双机热备的方式,可以实现SQL Server数据库的高可用;

扩展: SQL Server数据库集群采用共存存储的方式,通过硬件垂直升级来对数据库集群进行扩展;

3、适用场景:大多数OLTP场景(与微软体系配合)
4、选择注意:
SQL Server与微软技术体系结合比较紧密,绝大多数工作,都是通过图形界面完成,对于习惯使用命令行的DBA可能会有不习惯;

SQL server对双引号,大小写,元信息的管理和处理方式,与其他数据库很不相同,需要注意;

使用SQL Server满足OLTP业务,会有比较好的效果,但对于大数据量的OLAP业务,最好还是选用专门的OLAP架构,不要在同一个SQL Server实例上混用OLTP和OLAP业务;

SQL server属于商业软件,需要注意版权和licence授权费用;

第三种武器:Oracle数据库

1、定位:
商业、多平台、关系型数据库

功能最强大、最复杂、市场占比最高的商业数据库

2、特点:

功能:支持事务,符合关系型数据库原理,符合ACID,支持多数SQL规范,以二维表方式组织数据

部署:Oracle单实例数据库部署相对容易,但Oracle RAC集群环境,部署的步骤和依赖条件都比较多;

使用:通常使用命令行工具,进行各种数据库的管理,通常也可以用shell脚本和python脚本提高Oracle数据库管理效率;各种管理功能,都比较强大;

监控:Oracle官方有比较全面的监控工具,常用的第三方监控平台,如zabbix,cacti,lepus等都有对Oracle数据库的各项指标的完善监控;

备份:支持冷备份和热备份,可以用 exp/imp , expdp/impdp等进行逻辑备份和恢复,可以使用强大的RMAN工具进行专业的物理热备份和恢复;

高可用:Oracle数据库的高可用架构,可以用第三方双机热备软件,结合Oracle单实例实现;可以使用Oracle Dataguard,实现master和standby的备份;可以使用 Oracle RAC集群实现实例级别的高可用和负载均衡,使用ASM实现存储级别的高可用;

扩展:由于Oracle集群采用共享存储的方式,一般只能通过垂直硬件升级进行升级;

3、适用场景:绝大多数OLTP场景,部分OLAP

4、选择注意:Oracle从架构到运维,可以说是最难的数据库,学习和使用难度较高。

第四种武器:Postgresql数据库

1、定位:开源、多平台、关系型数据库,功能最强大的开源数据库。
2、特点:
功能:支持事务,符合关系型数据库原理,符合ACID,支持多数SQL规范,以二维表方式组织数据;

部署: postgresql需要先准备好Python等环境,然后编译安装软件,初始化数据库,启动实例,整个部署过程相对比较清晰;

使用: postgresql数据库可以使用命令行方式进行管理,也可以通过pgadmin图形工具进行管理;各种管理功能,都比较强大;

监控: 可以再命令行中查看各种性能视图和状态视图;相对其他其他数据库,并没有太好的图形监控工具和平台;

备份:支持冷备份和热备份,可以用 COPY命令进行逻辑导出和导入;用pgdump和pgrestore进行物理备份和恢复;

高可用:postgresql 官方支持 master-standby复制;也可以用Slony-I第三方组件进行数据库同步;

扩展:postgresql可以通过修改源码实现的postgres-XC实现水平扩展;

3、适用场景:

绝大多数OLTP场景,部分OLAP

适合目前互联网需要的一些信息,比如地理位置信息处理;

以postgresql作为底层数据库的greenplum数据仓库,是主流的MPP数据仓库;

基于postgresql的TimeScaleDB,是目前比较火的时序数据库之一;

4、选择注意:
Postgresql的架构、使用难度、功能性介于Oracle数据库和MySQL数据库之间,但因其开源的推动,各方面也有不错的发展;

Postgresql目前还没有比较主流和好用的监控平台,这是postgresql数据库目前存在的一个不足。

第五种武器:Mongodb数据库

1、定位:开源、多平台、文档型nosql数据库
非常主流的文档型nosql数据库,“最像关系型数据库”,定位于“灵活”的nosql数据库

2、特点:
功能:数据文件存储格式为BSON,模式自由,整体架构与关系型数据库有对应关系,具有较好的高可用性和伸缩性,有插件式存储引擎,新版本默认是writedtiger存储引擎;

部署: 部署比较简答,下载软件,设置好配置文件即可启动服务;

使用:不支持SQL语句,使用与SQL对应的json方式管理数据库;

监控:有比较丰富的监控和性能命令,官方有比较完善的图形监控系统,但需要购买;

备份:支持冷备份和热备份,可以使用mongoexport/mongimport进行逻辑备份,也可以使用基于oplog的mongodump/mongorestore物理热备份;

高可用:MongoDB master-slave主从复制:在master节点上加 –master参数,从数据库加 -slave和-source参数,就可以实现同步,这种目前不建议;

ReplicaSets复制集,在mongodb 1.6之后,开发了新的 replicaset,着呢家了故障自动切换和自动修复成员节点,各个DB将数据一致,建议使用这种方式;可以测试读写分离和故障转移;

扩展:mongodb海量数据水平拆分,将数据分别存储在sharding各个节点上,构建出分布式集群。Sharding架构由 底层多个mongodb Shared Server,config水平拆分配置库config server,前端路由 route process,三部分构成。Sharding集群底层可以是mongodb单实例,也可以高可用的replicaSet复制集。

3、适用场景:

网站后台数据库:mongodb非常适合实话实说插入、更新与查询,并可以实时复制和高伸缩性,适合更新迭代快、需求变更多、以对象为主的网站应用;

小文件系统:对于json文件,二进制数据,适合用mongodb进行存储和查询

日志分析系统:对于数据量大的日志文件,IM会话消息记录,适合用mongodb来保存和查询;

缓存系统:mongodb数据库也会使用大量的内存,合理的设计,也可以作为缓存系统使用;不过目前缓存系统使用更多的方案是 memcached和redis。

4、选择注意:
Mongodb不适合的场景:

高度事务性的系统:即传统的OLTP业务,mongodb,乃至其他nosql,对事务性支持都不太好;

传统的统计分析应用:即传统的OLAP业务,需要高度优化的查询方式,mongodb支持不好;

使用SQL语句比较方便的业务:mongodb是json类型的查询方式,虽然也灵活,但不如用SQL方便,如果业务和适合SQL,则就不太合适mongodb了。

第六种武器:Redis数据库

1、定位:
开源、Linux平台、key-value键值型Nosql数据库

简单稳定,非常主流的、全数据in-momory、定位于“快”的键值型nosql数据库

2、特点:
功能: 命令执行速度非常看,读写性能可达10万/秒;数据结构是key-value类似字典的功能,可以键过期-缓存,发布订阅-消息系统,简单的事物功能;

部署: 用下载软件介质,编译安装的方式,可以很快完成数据库部署;服务启动redis-server,可以用默认配置、运行参数配置、配置文件启动,三种方式;redis在Linux平台支撑较好,官方没有Windows版本,微软维护了一个分支;

使用:用redis-cli客户端连接,一般用简单的 set ,get,del 进行数据管理; 在单实例redis的基础上,进行可以数据持久化,主从复制,高可用和分布式等功能;

监控:在命令行界面有一些常用的命令显示状态和性能,在图形界面方面,有开源监控工具来监控和记录数据库的状态,比如cachecloud;

备份:直接备份成物理问价的RDB持久化,基于AOF日志的实时AOF持久化

高可用:官方的 redis sentinel哨兵高可用集群

扩展:官方基于分配槽的 redis cluster分布式集群

3、适用场景:

缓存

基础消息队列系统

排行榜系统

计数器使用

社交网站的点赞、粉丝、下拉刷新等应用;

4、选择注意:

Redis的使用场景,是redis适合的解决的问题,也有不适合解决的问题。

从数据规模角度讲,小数据规模使用redis比较合适,大数据规模使用redis不合适;(大数据规模,在一定程度上,可以用SSDB替代redis使用);

从数据冷热角度看,热数据适合放在redis中,冷数据不适合放在redis中。

第七种武器:Hbase数据库

1、定位:开源、Linux平台、列存储nosql数据库
可用于海量数据存储、与Hadoop生态圈结合、定位于“大”的列存储nosql数据库

2、特点:

功能:命令执行速度非常看,读写性能可达10万/秒;数据结构是key-value类似字典的功能,可以键过期-缓存,发布订阅-消息系统,简单的事物功能;

部署:相对其他数据库,hbase的部署比较复杂,依赖Hadoop,zookeeper等组件,Hbase集群包括一个mater节点,多个regionServer,zookeeper管理所有regionServer,需要依次部署Hadoop、zookeeper之后,再部署HBASE集群;

使用:用redis-cli客户端连接,一般用简单的 set ,get,del 进行数据管理; 在单实例redis的基础上,进行可以数据持久化,主从复制,高可用和分布式等功能;

监控:在命令行界面有一些常用的命令显示状态和性能,在图形界面方面,有开源监控工具来监控和记录数据库的状态,比如cachecloud;

备份:Hbase一般用作海量数据的仓库,本身通过多层副本来保证数据安全性,不用进行专门的备份

高可用:HBASE集群基于Hadoop,需要依次部署Hadoop单机模式、集群模式、HA模式,通过Hadoop HA实现高可用;

扩展:HBASE以集群形式,依次是单机模式,伪分布模式,完全分布模式,底层基于HDFS,zookeeper可以很好地进行扩展;

3、适用场景:

两大用途:

用于简单数据写入和海量、结构简单数据查询的业务场景;

用于成为其他数据库备份和下沉的数据库;

4、选择注意:
Hbase不适合的场景:对数据分析需求高,需要能够用sql或者简单的MapReduce实现分析需求的业务场景,不适合用Hbase;

单表数据量,不超过千万时,使用Hbase,体现不出Hbase的优势,而且会比较慢,不适合用Hbase。

通过对上面数据库“七种”武器的描述,也可以看到目前常用数据库的使用脉络和选择顺序,对应一个业务,可以优先选择最流行的开源数据库——MySQL;如果出于稳定和商业版考虑,可以选择Oracle数据库,或者SQL Server数据库(与Windows体系结合);如果想用开源,有想要有足够的功能来应对各种场景,可以使用 postgresql数据库。这四种数据库,都是关系型数据库,可以很好地满足大多数业务场景,解决通用性问题。

对于一些特殊性问题,尤其是想要在扩展性方面有比较高的要求,可以考虑nosql数据库。Mongodb数据库,介于关系型数据库和非关系型数据库之间,兼具两者的特点,是非常流行的文档型nosql数据库;redis定位于内存型键值nosql数据库;hbase是海量文件存储的列式nosql数据库。根据合适的业务场景,选择适合的nosql数据库,可以对某一类,或某几类业务问题有很好的解决,可以作为关系型数据库的一种补充。

换个角度,MySQL,Oracle,SQL Server,Postgresql,mongodb这五种数据库,也是DB-Engines排行榜上最流行的排名前五的五种数据库,从使用量和受欢迎程度,也可以看出这些数据库使用的广泛性。

朱元璋的历史形象是怎样变差的

关于朱元璋的历史形象,一直以来都存在严重的两极分化。


两种真实性难以分辨的朱元璋画像

正史往往将他塑造成仁义的明君,野史则把他描述成残忍的暴君。清人赵翼就曾困惑地评价道:「盖(大概)明祖(朱元璋)一人,圣贤、豪杰、盗贼之性,实兼而有之者也。」

不少现代人也因为这种矛盾而产生了误解,认为有关朱元璋的「黑材料」都是清代官方的刻意「抹黑」。


不少现代人把朱元璋形象的「丑化」归结为清朝官方所为,尤其将矛头对准了「禁书修书」的乾隆帝

但事实上,从明仁宗洪熙朝开始,朱元璋的历史形象就已经出现了每况愈下的趋势。

在明朝建国初期,朱元璋的形象无疑是俊伟光鲜的。明朝的官修史书《明太祖实录》就称赞他是五帝之后,带有圣人基因。明初的文人士大夫更是在《洪武圣政记》等私人著述中吹嘘他德行高尚,功绩震古绝今。

而到了明成祖永乐年间,朱棣又进一步将这种个人崇拜推向了高潮。在永乐朝成书的《天潢玉牒》中,不但罗列了朱元璋礼贤下士、勤奋好学、徐怀纳言等优秀品质。还记录了大量有关朱元璋的神异事件,试图利用「天命所归」的暗示,把朱元璋的个人形象「神格化」。

除了极力美化朱元璋外,《天潢玉牒》还特地把朱棣的生母说成了马皇后。这种与史实不符的记载,反映出该书浓烈的政治倾向。

洪武朝对朱元璋的各类溢美之词尚可理解,毕竟他终结了元末乱世,创造了和平的局面,国计民生都因此得以复苏。再加上朱元璋喜好严刑峻法,大搞政治迫害,文人出于避祸的心理,也不敢妄谈国事。

但永乐朝对朱元璋的夸大吹捧就颇值得玩味了。这一方面固然是因为朱棣起兵时打出的口号就是恢复洪武旧制,另一方面则源于朱元璋和朱棣在作为上的相似性。

朱棣很清楚,褒扬太祖就相当于褒扬自己,抨击太祖就相当于抨击自己。所以,永乐朝吹捧朱元璋的风气超过了他在世的洪武朝,达到了历史顶点。


和朱元璋一样,朱棣在位期间不仅事业有成,同时也杀戮了大量政治异见者

不过,明朝对朱元璋的这般吹捧也就只维持了约半个世纪。自明仁宗朱高炽继位开始,情况就发生了显著的转变。在洪熙朝到成化朝的六十多年间,虽然文人士大夫仍然对朱元璋褒扬有加,但批评的声音也逐渐流传开来。

永乐朝以后,明仁宗和明宣宗为了重建士大夫阶级的道德标杆,平反了深受朱棣迫害的建文朝大臣。原本被封禁的建文朝著作,也随之得到了解禁。这些著作揭露了朱元璋在位时期的不少冤案,对后世评价洪武朝的政治具有极大的参考价值。

例如,方孝孺的《逊志斋集》,就涉及了大量洪武朝的「黑材料」。它披露了洪武十五年发生的「空印案」,提及了许多朱元璋不纳忠言、乱杀谏臣的史实。这些事件株连甚广,被杀和被流放的官员达数千人,但洪武、永乐朝的其他史料(如官修《明实录》)却视若无睹,没有加以记载。


方孝孺的著作揭露了洪武朝的很多未载于正史的「黑幕」

伴随着对建文朝臣子的平反,尤其是明代初叶那种紧张的政治风气逐渐松弛,文人士大夫不但有了阅读《逊志斋集》一类黑材料的机会,还大量以之为依据,用来批评朱元璋时期专断暴戾的执政风格。

特别是正统朝发生「土木堡之变」后,明朝政治日趋腐朽,国家实力逐渐衰微。文人士大夫阶层受此影响,不再沉溺于对皇帝的个人崇拜,反而试图从前朝事例中寻找经验教训。从很多当时留下的论述里可以看出,中明的文人士大夫表面上批判的是朱元璋,实际上是想用朱元璋的例子警示本朝皇帝。


自明英宗以来,明朝皇帝昏招迭出,致使文人士大夫不得不反思过去一味给皇帝「捧臭脚」的政治风气

当然,这些关于朱元璋的「黑材料」也并非全无问题。特别是有关洪武文字狱的记载,存在明显的夸大,甚至互相矛盾。后世有关洪武文字狱的大部分故事来自于《朝野异闻录》和《闲中今古录》一类的野史。现代明史专家经过对大量不同史料的分析,除了发现洪武文字狱确有其事外,也从这类野史中发现了不少杜撰的故事。

而且越到这段「平反浪潮」的后期,对朱元璋的杜撰式「抹黑」越严重。尤其是在中晚明,出现了肆意篡改书籍的风气,导致文人有意在原有史料的基础上添油加醋,把朱元璋丑化为一个粗俗的流氓。相比前期的客观还原真相,后期的朱元璋形象已经变得惨不忍睹。以至于著名明史专家陈学霖认为:「现存有关明初文字狱史料不宜轻信。」

讽刺的是,到了十六、十七世纪,随着明朝北部边疆的战局日益吃紧,特别是明亡以后抗清形势的需要,文人士大夫对朱元璋的评价再次发生了一百八十度转变,成了一副「驱除鞑虏、恢复中华」的英明形象。这也使得明代朱元璋的形象,在演变过程中形成了一种有趣的历史循环。

薛仁贵祖孙三代互相杀害的内情

一代名将竟被亲儿子射杀!薛仁贵祖孙三代互相杀害的内情

话说唐朝太宗时期,山西龙门县有个薛仁贵,力大无穷,武艺超群,箭法高强,因家境贫穷,所以到本村柳姓地主家做工,因缘际会,和柳家小姐柳迎春私定终身,柳员外见薛仁贵一表人材,也就没有反对,顺势同意了这门亲事。二人婚后不久,东辽国盖苏文打下战表,要夺大唐江山,薛仁贵辞别娇妻,前去投军,一去多年,后来薛仁贵百日双救驾,三箭定东辽,被封为两辽王,这才衣锦还乡。

薛仁贵

  薛仁贵带领人马返回龙门县,准备接妻子上京享福,所谓近乡情更怯,离家这么久,自己岳父一家如何了,妻子如何了,临走的时候,妻子已经身怀有孕,也不知是男是女。薛仁贵正恍惚之间,忽然间看到前面小树林有一小男孩在练习武艺,小男孩年龄虽小,一身武艺却极为高明,薛仁贵正看着,突然之间,发现从林中窜出一只猛虎,向着小男孩扑去,千钧一发之间,薛仁贵射出了一箭,准备救下小男孩,哪知道阴差阳错,他这一箭没有射中猛虎,却正中小男孩的咽喉,一箭射死了这孩子,猛虎直接把孩子给叼走了。薛仁贵虽然伤心后悔,却也无可奈何。

  回到家之后,见到久别的妻子,夫妻二人互诉离别之苦,薛仁贵这才知道自己有了个儿子,孩子去后山小树林练武去了,薛仁贵心里一想,派人一查,这才知道,自己一箭射死的孩子,竟然是自己的亲儿子薛丁山,夫妻二人,自然又是一番伤心。

  后来西凉国造反,薛仁贵挂帅征西,被困在锁阳关,薛丁山下山救父,原来薛丁山当时被射一箭,并没有死,被他师父王禅老祖所救,一直跟着老师在山上学艺。后来听说自己父亲被困锁阳关,这才请求老师,让他下山。薛丁山下山之后,校场比武,挂了二路元帅,在锁阳关救出了自己父亲,父子见面,抱头痛哭,一家人才算是得以团圆。

薛丁山

  征西途中,白虎关大帅杨凡,摆下大阵,困住了薛仁贵,薛丁山为救父亲,亲自领兵破阵,攻打了三天三夜,总算把大阵破了。薛丁山策马冲进阵内,正看到自己父亲和杨凡大战,父亲被困数日,体力不支,马上就要被杨凡斩于马下,薛丁山一见非常着急,搭弓拉箭,一箭射出,想箭射杨凡,救出自己父亲,结果一箭射偏,正中薛仁贵咽喉,当场把薛仁贵给射死了。父子二人,相互射杀,这也算是结束了一段因果。

  薛仁贵本是白虎星转世,薛丁山却是金童转世,白虎被杀之后,心中不服,再次转世成为薛丁山之子薛刚,准备择机找薛丁山报仇。后来薛刚正月十五闹花灯,脚踢太子,惊崩圣驾,老薛家数百口,包括薛丁山在内,被武则天全部杀死,而薛刚则趁机逃跑了,后来西凉借兵,抓住了武则天,这才给薛家报了仇。

薛刚

  薛仁贵祖孙三代,相互杀害,虽然全是无意为之,但不能不说,冥冥之中似有天意,薛仁贵的遭遇,在古代名将之中,也算是独一份,让后人可怜叹息。

YII2 框架访问gii页面404的错误处理记录

常见错误通过 Baidu 或 Google 可以找到,通常是安装、基本配置问题。

今天在本地使用GII的过程中,遇到的404问题,根据网上的解决方案,都没能够解决,通过debug,发现问题出在了UrlManager的配置上。

根据网上的教程,GII安装好以后,通过链接 “http://localhost/app/gii” 即可直接访问。但是在本机测试无论如何也是返回404,反复修改配置文件,也没能解决这个问题。

通过调试代码最终发现问题出在了下面的配置上

urlManager配置了后缀为’.html’,在使用链接 “http://localhost/app/gii” 访问时,由于没有后缀,YII框架在解析URL时,就直接返回404了,所以在配置了’suffix’属性的时候,需要使用链接 “http://localhost/app/gii.html” ,或者不配置’suffix’属性即可。

禁用apache OPTIONS方法

使用apache的重写规则来禁用OPTIONS方法。方法如下:

在apache配置文件http.conf中添加以下代码:

参考文章:
http://www.techstacks.com/howto/disable-http-methods-in-apache.html

http://www.linuxquestions.org/questions/linux-security-4/disabling-head-options-http-methods-in-apache-webserver-763347/

linux运维常用命令一句话

整理收集一些Linux运维管理、系统管理的常用命令,太多了记不住,只能记录下来方便日后查看。也可以和大家分享。如果你有好的一句话命令也贴出来吧。本文持续更新中。

1、linux启动过程

开启电源 –> BIOS开机自检 –> 引导程序lilo或grub –> 内核的引导(kernel boot)–> 执行init(rc.sysinit、rc)–> mingetty(建立终端) –> Shell

2、网卡绑定多IP

3、设置DNS、网关

4、弹出、收回光驱

5、用date查询昨天的日期

6、查询file1里面空行的所在行号

7、查询file1以abc结尾的行

8、打印出file1文件第1到第三行

9、清空文件

10、删除所有空目录

11、linux下批量删除空文件(大小等于0的文件)的方法

12、删除五天前的文件

13、删除两个文件重复的部份,打印其它

14、攻取远程服务器主机名

15、实时监控网卡流量(安装iftop)

16、查看系统版本

17、强制踢出登陆用户

18、tar增理备份、还原

19、将本地80端口的请求转发到8080端口,当前主机外网IP为202.96.85.46

20、在11月份内,每天的早上6点到12点中,每隔2小时执行一次/usr/bin/httpd.sh

21、查看占用端口8080的进程

22、在Shell环境下,如何查看远程Linux系统运行了多少时间?

23、查看CPU使用情况的命令

每5秒刷新一次,最右侧有CPU的占用率的数据

top 然后按Shift+P,按照进程处理器占用率排序

24、查看内存使用情况的命令

用free命令查看内存使用情况

top 然后按Shift+M, 按照进程内存占用率排序

25、查看磁盘i/o

用iostat查看磁盘/dev/sdc3的磁盘i/o情况,每两秒刷新一次

26、修复文件系统

-t 指定文件系统
-y 对发现的问题自动回答yes

27、read 命令5秒后自动退出

28、grep -E -P 是什么意思

-E, –extended-regexp 采用扩展正规表达式。
-P,–perl-regexp 采用perl正规表达式

29、vi编辑器(涉及到修改,添加,查找)

插入(insert)模式

i     光标前插入
I     光标行首插入
a     光标后插入
A     光标行尾插入
o     光标所在行下插入一行,行首插入
O     光标所在行上插入一行,行首插入
G     移至最后一行行首
nG    移至第n行行首
n+    下移n行,行首
n-    上移n行,行首
:/str/          从当前往右移动到有str的地方
:?str?          从当前往左移动到有str的地方
:s/str1/str2/       将找到的第一个str1替换为str2  
:s/str2/str2/g      将当前行找到的所有str1替换为str2
:n1,n2s/str1/str2/g    将从n1行至n2行找到的所有的str1替换为str2
:1,.s/str1/str2/g     将从第1行至当前行的所有str1替换为str2
:.,$s/str1/str2/g     将从当前行至最后一行的所有str1替换为str2

30、linux服务器之间相互复制文件

copy 本地文件1.sh到远程192.168.9.10服务器的/data/目录下

copy远程192.168.9.10服务器/data/2.sh文件到本地/data/目录

31、使用sed命令把test.txt文件的第23行的TEST换成TSET.

32、使history命令能显示时间

33、如何查看目标主机192.168.0.1开放那些端口

34、如何查看网络连接

35、如何查看当前系统使用了那些库文件

36、如何查看网卡的驱动版本

37、使用tcpdump来监视主机192.168.0.1的tcp的80端口

38、 如何看其它用户的邮件列表

39、对大文件进行切割

按每个文件1000行来分割

按照每个文件5m来分割

40、合并文件

取出两个文件的并集(重复的行只保留一份)

取出两个文件的交集(只留下同时存在于两个文件中的文件)

删除交集,留下其他的行

41、打印文本模式下运行的服务

42、删除0字节文件

43、查看进程,按内存从大到小排列

44、查看http的并发请求数及其TCP连接状态

45、获取IP地址

perl实现获取IP地址:

46、获取内存大小

47、查看CPU核心数

48、查看磁盘使用情况

49、查看有多少个活动的PHP-cgi进程

50、查看硬件制造商