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排行榜上最流行的排名前五的五种数据库,从使用量和受欢迎程度,也可以看出这些数据库使用的广泛性。

MySQL Hash索引和B-Tree索引的区别

MySQL Hash索引和B-Tree索引的区别究竟在哪里呢?相信很多人都有这样的疑问,下文对两者的区别进行了详细的分析,供您参考。

MySQL Hash索引结构的特殊性,其检索效率非常高,索引的检索可以一次定位,不像B-Tree 索引需要从根节点到枝节点,最后才能访问到页节点这样多次的IO访问,所以 Hash 索引的查询效率要远高于 B-Tree 索引。
可 能很多人又有疑问了,既然 Hash 索引的效率要比 B-Tree 高很多,为什么大家不都用 Hash 索引而还要使用 B-Tree 索引呢?任何事物都是有两面性的,Hash 索引也一样,虽然 Hash 索引效率高,但是 Hash 索引本身由于其特殊性也带来了很多限制和弊端,主要有以下这些。

(1)MySQL Hash索引仅仅能满足”=”,”IN”和”<=>”查询,不能使用范围查询。

由于 MySQL Hash索引比较的是进行 Hash 运算之后的 Hash 值,所以它只能用于等值的过滤,不能用于基于范围的过滤,因为经过相应的 Hash 算法处理之后的 Hash 值的大小关系,并不能保证和Hash运算前完全一样。

(2)MySQL Hash索引无法被用来避免数据的排序操作。

由于 MySQL Hash索引中存放的是经过 Hash 计算之后的 Hash 值,而且Hash值的大小关系并不一定和 Hash 运算前的键值完全一样,所以数据库无法利用索引的数据来避免任何排序运算;

(3)MySQL Hash索引不能利用部分索引键查询。

对于组合索引,Hash 索引在计算 Hash 值的时候是组合索引键合并后再一起计算 Hash 值,而不是单独计算 Hash 值,所以通过组合索引的前面一个或几个索引键进行查询的时候,Hash 索引也无法被利用。

(4)MySQL Hash索引在任何时候都不能避免表扫描。

前面已经知道,Hash 索引是将索引键通过 Hash 运算之后,将 Hash运算结果的 Hash 值和所对应的行指针信息存放于一个 Hash 表中,由于不同索引键存在相同 Hash 值,所以即使取满足某个 Hash 键值的数据的记录条数,也无法从 Hash 索引中直接完成查询,还是要通过访问表中的实际数据进行相应的比较,并得到相应的结果。

(5)MySQL Hash索引遇到大量Hash值相等的情况后性能并不一定就会比B-Tree索引高。

对于选择性比较低的索引键,如果创建 Hash 索引,那么将会存在大量记录指针信息存于同一个 Hash 值相关联。这样要定位某一条记录时就会非常麻烦,会浪费多次表数据的访问,而造成整体性能低下。

MySQL SHOW命令汇总

a. show tablesshow tables from database_name; — 显示当前数据库中所有表的名称
b. show databases; — 显示 mysql 中所有数据库的名称
c. show columns from table_name from database_name;show columns from database_name.table_name; — 显示表中列名称
d. show grants for user_name; — 显示一个用户的权限,显示结果类似于grant 命令
e. show index from table_name; — 显示表的索引
f. show status; — 显示一些系统特定资源的信息,例如,正在运行的线程数量
g. show variables; — 显示系统变量的名称和值
h. show processlist; — 显示系统中正在运行的所有进程,也就是当前正在执行的查询。大多数用户可以查看他们自己的进程,但是如果他们拥有process权限,就可以查看所有人的进程,包括密码。
i. show table status; — 显示当前使用或者指定的database中的每个表的信息。信息包括表类型和表的最新更新时间
j. show privileges; — 显示服务器所支持的不同权限
k. show create database database_name; — 显示create database 语句是否能够创建指定的数据库
l. show create table table_name;— 显示create database 语句是否能够创建指定的数据库
m. show engies; — 显示安装以后可用的存储引擎和默认引擎。
n. show innodb status; — 显示innoDB存储引擎的状态
o. show logs; — 显示BDB存储引擎的日志
p. show warnings; — 显示最后一个执行的语句所产生的错误、警告和通知
q. show errors; — 只显示最后一个执行语句所产生的错误
r. show [storage] engines; –显示安装后的可用存储引擎和默认引擎
s. show procedure status –显示数据库中所有存储的存储过程基本信息,包括所属数据库,存储过程名称,创建时间等
t. show create procedure sp_name –显示某一个存储过程的详细信息

语法:MySQL中INSERT INTO SELECT的使用

语法介绍

有三张表a、b、c,现在需要从表b和表c中分别查几个字段的值插入到表a中对应的字段。对于这种情况,可以使用如下的语句来实现:

上面的语句比较适合两个表的数据互插,如果多个表就不适应了。对于多个表,可以先将需要查询的字段JOIN起来,然后组成一个视图后再SELECT FROM就可以了:

其中f1是表b的字段,f2是表c的字段,通过JOIN查询就将分别来自表b和表c的字段进行了组合,然后再通过SELECT嵌套查询插入到表a中,这样就满足了这个场景了,如果需要不止2个表,那么可以多个JOIN的形式来组合字段。

语法错误注意

需要注意的是嵌套查询部分最后一定要有设置表别名,如下:

即最后的AS tb是必须的(tb这个名称可以随意取),即指定一个别名。每个派生出来的新表都必须指定别名,否则在mysql中会报如下错误:
ERROR 1248 (42000): Every derived TABLE must have its own alias

另外,MySQL中INSERT INTO SELECT不能加VALUES,即不能写成如下形式:

否则也会报错:You have an error in your SQL syntax

mysql远程连接错误1130的解决方法

解决远程连接mysql错误1130代码的方法

今天在用远程连接Mysql服务器的数据库,不管怎么弄都是连接不到,错误代码是1130,ERROR 1130: Host 192.168.2.159 is not allowed to connect to this MySQL server
猜想是无法给远程连接的用户权限问题。结果这样子操作mysql库,即可解决。在本机登入mysql后,更改 “mysql” 数据库里的 “user” 表里的 “host” 项,从”localhost”改称’%’。。

第一句:以权限用户root登录
第二句:选择mysql库
第三句:查看mysql库中的user表的host值(即可进行连接访问的主机/IP名称)
第四句:修改host值(以通配符%的内容增加主机/IP地址),当然也可以直接增加IP地址
第五句:刷新MySQL的系统权限相关表
第六句:再重新查看user表时,有修改。。
重起mysql服务即可完成。


本机的mysql数据库中有两条user=’root’的记录,将其中一条host=’localhost’的host修改为’%’后,虽然可以通过远程访问数据库了,但是使用localhost或者127.0.0.1又无法访问数据库了。

经过一番折腾,发现可以通过创建用户的方法来解决这个问题。不需要修改user表中的任何数据,在本地用root登陆mysql后,执行下面的语句,创建用户名为’root’,密码为’123456’的用户。执行完以后,查看user表,发现新增了一条host=’%’,user=’root’的记录,并且各项权限与其它’root’一样,再次使用192.168.1.13进行访问,发现可以正常访问了。

如果访问还有问题,可以执行一下flush privileges;

MySQL修改root密码的各种方法整理

整理了以下四种在MySQL中修改root密码的方法,可能对大家有所帮助!

方法1: 用SET PASSWORD命令

方法2:用mysqladmin

如果root已经设置过密码,采用如下方法

方法3: 用UPDATE直接编辑user表

在丢失root密码的时候,可以这样