Mysql是列式存储吗，或者说mysql支持列式存储吗？

大数据（巨量数据集合（IT行业术语））

大数据（big data），指无法在可承受的时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力来适应海量、高增长率和多样化的信息资产。

压缩表从名字上来看，简单理解为压缩后的表，也就是把原始表根据一定的压缩算法按照一定的压缩比率压缩后生成的表。

1.1 压缩能力强的产品

表压缩后从磁盘占用上看要比原始表要小很多。如果你熟悉列式数据库，那对这个概念一定不陌生。比如，基于 PostgreSQL 的列式数据库 Greenplum；早期基于 MySQL 的列式数据库 inforbright；或者 Percona 的产品 tokudb 等，都是有压缩能力非常强的数据库产品。

1.2 为什么要用压缩表？

情景一：磁盘大小为 1T，不算其他的空间占用，只能存放 10 张 100G 大小的表。如果这些表以一定的比率压缩后，比如每张表从 100G 压缩到 10G，那同样的磁盘可以存放 100 张表，表的容量是原来的 10 倍。情景二：默认 MySQL 页大小 16K，而 OS 文件系统一般块大小为 4K，所以在 MySQL 在刷脏页的过程中，有一定的概率出现页没写全而导致数据坏掉的情形。比如 16K 的页写了 12K，剩下 4K 没写成功，导致 MySQL 页数据损坏。这个时候就算通过 Redo Log 也恢复不了，因为几乎有所有的关系数据库采用的 Redo Log 都记录了数据页的偏移量，此时就算通过 Redo Log 恢复后，数据也是错误的。所以 MySQL 在刷脏数据之前，会把这部分数据先写入共享表空间里的 DOUBLE WRITE BUFFER 区域来避免这种异常。此时如果 MySQL 采用压缩表，并且每张表页大小和磁盘块大小一致，比如也是 4K，那 DOUBLE WRITE BUFFER 就可以不需要，这部分开销就可以规避掉了。查看文件系统的块大小：

root@ytt-pc:/home/ytt#  tune2fs -l /dev/mapper/ytt--pc--vg-root  | grep -i 'block size'Block size:               4096

1.3 压缩表的优势

压缩表的优点非常明显，占用磁盘空间小！由于占用空间小，从磁盘置换到内存以及之后经过网络传输都非常节省资源。

简单来讲：节省磁盘 IO，减少网络 IO。

1.4 压缩表的缺陷

当然压缩表也有缺点，压缩表的写入（INSERT,UPDATE,DELETE）比普通表要消耗更多的 CPU 资源。

压缩表的写入涉及到解压数据，更新数据，再压缩数据，比普通表多了解压和再压缩两个步骤，压缩和解压缩需要消耗一定的 CPU 资源。所以需要选择一个比较优化的压缩算法。

1.5 MySQL 支持的压缩算法

这块是 MySQL 所有涉及到压缩的基础，不仅仅用于压缩表，也用于其它地方。比如客户端请求到 MySQL 服务端的数据压缩；主从之间的压缩传输；利用克隆插件来复制数据库 *** 作的压缩传输等等。

从下面结果可以看到 MySQL 支持的压缩算法为 zlib 和 zstd，MySQL 默认压缩算法为 zlib，当然你也可以选择非 zlib 算法，比如 zstd。至于哪种压缩算法最优，暂时没办法简单量化，依赖表中的数据分布或者业务请求。

 MySQL数据库:

MySQL是一种开放源代码的关系型数据库管理系统（RDBMS），使用最常用的数据库管理语言--结构化查询语言（SQL）进行数据库管理。

MySQL是开放源代码的，因此任何人都可以在General Public License的许可下下载并根据个性化的需要对其进行修改。

MySQL因为其速度、可靠性和适应性而备受关注。大多数人都认为在不需要事务化处理的情况下，MySQL是管理内容最好的选择。

数据库简介:

MySQL是一种开放源代码的关系型数据库管理系统（RDBMS），MySQL数据库系统使用最常用的数据库管理语言--结构化查询语言（SQL）进行数据库管理。

由于MySQL是开放源代码的，因此任何人都可以在General Public License的许可下下载并根据个性化的需要对其进行修改。MySQL因为其速度、可靠性和适应性而备受关注。大多数人都认为在不需要事务化处理的情况下，MySQL是管理内容最好的选择。

MySQL这个名字，起源不是很明确。一个比较有影响的说法是，基本指南和大量的库和工具带有前缀“my”已经有10年以上，而且不管怎样，MySQL AB创始人之一的Monty Widenius的女儿也叫My。这两个到底是哪一个给出了MySQL这个名字至今依然是个迷，包括开发者在内也不知道。

MySQL的海豚标志的名字叫“sakila”，它是由MySQL AB的创始人从用户在“海豚命名”的竞赛中建议的大量的名字表中选出的。获胜的名字是由来自非洲斯威士兰的开源软件开发者Ambrose Twebaze提供。根据Ambrose所说，Sakila来自一种叫SiSwati的斯威士兰方言，也是在Ambrose的家乡乌干达附近的坦桑尼亚的Arusha的一个小镇的名字。

MySQL，虽然功能未必很强大，但因为它的开源、广泛传播，导致很多人都了解到这个数据库。它的历史也富有传奇性。

MySQL数据库历史:

MySQL的历史最早可以追溯到1979年，那时Oracle也才小打小闹，微软的SQL Server影子都没有。有一个人叫Monty Widenius, 为一个叫TcX的小公司打工，并用BASIC设计了一个报表工具，可以在4M主频和16KB内存的计算机上运行。过了不久，又将此工具，使用C语言重写，移植到Unix平台，当时，它只是一个很底层的面向报表的存储引擎。这个工具叫做Unireg。

可是，这个小公司资源有限，Monty天赋极高，面对资源有限的不利条件，他反而更能发挥潜能，总是力图写出最高效的代码。并因此养成了习惯。与Monty同在一起的还有一些别的同事，很少有人能坚持把那些代码持续写到20年后，而Monty却做到了。

1990年，TcX的customer 中开始有人要求要为它的API提供SQL支持，当时，有人想到了直接使用商用数据库算了，但是Monty觉得商用数据库的速度难令人满意。于是，他直接借助于mSQL的代码，将它集成到自己的存储引擎中。但不巧的是，效果并不太好。于是, Monty雄心大起，决心自己重写一个SQL支持。

1996年，MySQL 1.0发布,只面向一小拨人，相当于内部发布。到了96年10月，MySQL 3.11.1发布了，呵呵，没有2.x版本。最开始，只提供了Solaris下的二进制版本。一个月后，Linux版本出现了。

紧接下来的两年里，MySQL依次移植到各个平台下。它发布时，采用的许可策略，有些与众不同：允许免费商用，但是不能将MySQL与自己的产品绑定在一起发布。如果想一起发布，就必须使用特殊许可，意味着要花银子。当然，商业支持也是需要花银子的。其它的，随用户怎么用都可以。这种特殊许可为MySQL带来了一些收入，从而为它的持续发展打下了良好的基础。（细想想，PostgreSQL曾经有几年限入低谷，可能与它的完全免费，不受任何限制有关系）。

MySQL3.22应该是一个标志性的版本，提供了基本的SQL支持。

MySQL关系型数据库于1998年1月发行第一个版本。它使用系统核心提供的多线程机制提供完全的多线程运行模式，提供了面向C、C++、Eiffel、Java、Perl、PHP、Python以及Tcl等编程语言的编程接口（APIs），支持多种字段类型并且提供了完整的 *** 作符支持查询中的SELECT和WHERE *** 作。

MySQL是开放源代码的，因此任何人都可以在General Public License的许可下下载并根据个性化的需要对其进行修改。MySQL因为其速度、可靠性和适应性而备受关注。

1999-2000年，有一家公司在瑞典成立了，叫MySQL AB (AB是瑞典语“股份公司”的意思)。 雇了几个人,与Sleepycat合作，开发出了 Berkeley DB引擎, 因为BDB支持事务处理，所以，MySQL从此开始支持事务处理了。

2000年4月，MySQL对旧的存储引擎进行了整理，命名为MyISAM。同时，2001年，Heikiki Tuuri向MySQL提出建议，希望能集成他们的存储引擎InnoDB，这个引擎同样支持事务处理，还支持行级锁。

如今，遗憾的是，BDB和InnoDB好像都被Oracle收购了，为了消灭竞争对手，哪怕是开源的，都是不择手段。

MySQL与InnoDB的正式结合版本是4.0。

到了MySQL5.0，2003年12月，开始有View,存储过程之类的东东，当然，其间, bug也挺多。

在2008年1月16号 MySQL被Sun公司收购。

最近，MySQL的创始人Monty Widenius已经向Sun提交了辞呈。head都要走了。

据说，被Sun收购的公司多薄命，不知道MySQL今后前途如何，希望一路走好。相信MySQL的生命力还是很长久的。

时至今日 mysql 和 php 的结合绝对是完美.很多大型的网站也用到mysql数据库.mysql的发展前景是非常光明的!

MySQL常用命令:

1:使用SHOW语句找出在服务器上当前存在什么数据库：

mysql>SHOW DATABASES

2: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’

全局管理权限对应解释：

FILE: 在MySQL服务器上读写文件。

PROCESS: 显示或杀死属于其它用户的服务线程。

RELOAD: 重载访问控制表，刷新日志等。

SHUTDOWN: 关闭MySQL服务。

数据库/数据表/数据列权限：

ALTER: 修改已存在的数据表(例如增加/删除列)和索引。

CREATE: 建立新的数据库或数据表。

DELETE: 删除表的记录。

DROP: 删除数据表或数据库。

INDEX: 建立或删除索引。

INSERT: 增加表的记录。

SELECT: 显示/搜索表的记录。

UPDATE: 修改表中已存在的记录。

特别的权限：

ALL: 允许做任何事(和root一样)。

USAGE: 只允许登录–其它什么也不允许做。

MySQL数据库导入方法:

MySQL数据库的导入,有两种方法：

1) 先导出数据库SQL脚本，再导入；

2) 直接拷贝数据库目录和文件。

在不同 *** 作系统或MySQL版本情况下，直接拷贝文件的方法可能会有不兼容的情况发生。

所以一般推荐用SQL脚本形式导入。下面分别介绍两种方法。

2. 方法一 SQL脚本形式

*** 作步骤如下：

2.1. 导出SQL脚本

在原数据库服务器上，可以用phpMyAdmin工具，或者mysqldump命令行，导出SQL脚本。

2.1.1 用phpMyAdmin工具

导出选项中，选择导出“结构”和“数据”，不要添加“DROP DATABASE”和“DROP TABLE”选项。

选中“另存为文件”选项，如果数据比较多，可以选中“gzipped”选项。

将导出的SQL文件保存下来。

2.1.2 用mysqldump命令行

命令格式

mysqldump -u 用户名 -p 数据库名 >数据库名.sql

范例：

mysqldump -u root -p abc >abc.sql

（导出数据库abc到abc.sql文件）

提示输入密码时，输入该数据库用户名的密码。

2.2. 创建空的数据库

通过主控界面/控制面板，创建一个数据库。假设数据库名为abc，数据库全权用户为abc_f。

2.3. 将SQL脚本导入执行

同样是两种方法，一种用phpMyAdmin（mysql数据库管理）工具，或者mysql命令行。

2.3.1 用phpMyAdmin工具

从控制面板，选择创建的空数据库，点“管理”，进入管理工具页面。

在"SQL"菜单中，浏览选择刚才导出的SQL文件，点击“执行”以上载并执行。

注意：phpMyAdmin对上载的文件大小有限制，php本身对上载文件大小也有限制，如果原始sql文件

比较大，可以先用gzip对它进行压缩，对于sql文件这样的文本文件，可获得1:5或更高的压缩率。

gzip使用方法：

# gzip xxxxx.sql

得到

xxxxx.sql.gz文件。

提示输入密码时，输入该数据库用户名的密码。

3 直接拷贝

如果数据库比较大，可以考虑用直接拷贝的方法，但不同版本和 *** 作系统之间可能不兼容，要慎用。

3.1 准备原始文件

用tar打包为一个文件

3.2 创建空数据库

3.3 解压

在临时目录中解压，如：

cd /tmp

tar zxf mydb.tar.gz

3.4 拷贝

将解压后的数据库文件拷贝到相关目录

cd mydb/

cp * /var/lib/mysql/mydb/

对于FreeBSD:

cp * /var/db/mysql/mydb/

3.5 权限设置

将拷贝过去的文件的属主改为mysql:mysql，权限改为660

chown mysql:mysql /var/lib/mysql/mydb/*

chmod 660 /var/lib/mysql/mydb/*

Mssql转换mysql的方法:

1.导表结构

使用MySQL生成create脚本的方法。找到生成要导出的脚本，按MySQL的语法修改一下到MySQL数据库中创建该表的列结构什么的。

2.导表数据

在MSSQL端使用bcp导出文本文件:

bcp “Select * FROM dbname.dbo.tablename” queryout tablename.txt -c -Slocalhost\db2005 -Usa

其中”"中是要导出的sql语句,-c指定使用\t进行字段分隔,使用\n进行记录分隔,-S指定数据库服务器及实例,-U指定用户名,-P指定密码.

在MySQL端使用mysqlimport 导入文本文件到相应表中

mysqlimport -uroot -p databasename /home/test/tablename.txt

其中-u指定用户名,-p指定密码,databasename指定数据库名称,表名与文件名相同

MySQL备份与恢复:

MySQL备份恢复数据的一般步骤

备份一个数据库的例子：

1、备份前读锁定涉及的表

mysql>LOCK TABLES tbl1 READ,tbl1 READ,…

如果，你在mysqldump实用程序中使用--lock-tables选项则不必使用如上SQL语句。

2、导出数据库中表的结构和数据

shell>mysqldump --opt db_name>db_name.sql

3、启用新的更新日志

shell>mysqladmin flush-logs

这样可以记录你备份后的数据改变为恢复数据准备。

4、解除表的读锁

mysql>UNLOCK TABLES

为了加速上述过程，你可以这样做：

shell>mysqldump --lock-tables --opt db_name>db_name.sqlmysqladmin flush-logs

但是这样可能会有点小问题。上命令在启用新的更新日志前就恢复表的读锁，

在更新繁忙的站点，可能有备份后的更新数据没有记录在新的日志中。

现在恢复上面备份的数据库

1、对涉及的表使用写锁

mysql>LOCK TABLES tbl1 WRITE,tbl1 WRITE,…

2、恢复备份的数据

shell>mysql db_name <db_name.sql

3、恢复更新日志的内容

shell>mysql --one-database db_name <hostname.nnn

假设需要使用的日志名字为hostname.nnn

4、启用新的更新日志

shell>mysqladmin flush-logs

5、解除表的写锁

mysql>UNLOCK TABLES

希望上面的例子能给你启发，因为备份数据的手法多种多样，你所使用的和上面所述可能大不一样，但是对于备份和恢复中，表的锁定、启用新的更新日志的时机应该是类似的，仔细考虑这个问题。

MySQL数据库优化:

选择InnoDB作为存储引擎

大型产品的数据库对于可靠性和并发性的要求较高，InnoDB作为默认的MySQL存储引擎，相对于MyISAM来说是个更佳的选择。

优化数据库结构

组织数据库的schema、表和字段以降低I/O的开销，将相关项保存在一起，并提前规划，以便随着数据量的增长，性能可以保持较高的水平。

设计数据表应尽量使其占用的空间最小化，表的主键应尽可能短。·对于InnoDB表，主键所在的列在每个辅助索引条目中都是可复制的，因此如果有很多辅助索引，那么一个短的主键可以节省大量空间。

仅创建你需要改进查询性能的索引。索引有助于检索，但是会增加插入和更新 *** 作的执行时间。

InnoDB的ChangeBuffering特性

InnoDB提供了changebuffering的配置，可减少维护辅助索引所需的磁盘I/O。大规模的数据库可能会遇到大量的表 *** 作和大量的I/O，以保证辅助索引保持最新。当相关页面不在缓冲池里面时，InnoDB的changebuffer将会更改缓存到辅助索引条目，从而避免因不能立即从磁盘读取页面而导致耗时的I/O *** 作。当页面被加载到缓冲池时，缓冲的更改将被合并，更新的页面之后会刷新到磁盘。这样做可提高性能，适用于MySQL5.5及更高版本。

InnoDB页面压缩

InnoDB支持对表进行页面级的压缩。当写入数据页的时候，会有特定的压缩算法对其进行压缩。压缩后的数据会写入磁盘，其打孔机制会释放页面末尾的空块。如果压缩失败，数据会按原样写入。表和索引都会被压缩，因为索引通常是数据库总大小中占比很大的一部分，压缩可以显著节约内存，I/O或处理时间，这样就达到了提高性能和伸缩性的目的。它还可以减少内存和磁盘之间传输的数据量。MySQL5.1及更高版本支持该功能。

注意，页面压缩并不能支持共享表空间中的表。共享表空间包括系统表空间、临时表空间和常规表空间。

使用批量数据导入

在主键上使用已排序的数据源进行批量数据的导入可加快数据插入的过程。否则，可能需要在其他行之间插入行以维护排序，这会导致磁盘I/O变高，进而影响性能，增加页的拆分。关闭自动提交的模式也是有好处的，因为它会为每个插入执行日志刷新到磁盘。在批量插入期间临时转移唯一键和外键检查也可显著降低磁盘I/O。对于新建的表，最好的做法是在批量导入后创建外键/唯一键约束。

一旦你的数据达到稳定的大小，或者增长的表增加了几十或几百兆字节，就应该考虑使用OPTIMIZETABLE语句重新组织表并压缩浪费的空间。对重新组织后的表进行全表扫描所需要的I/O会更少。

优化InnoDB磁盘I/O

增加InnoDB缓冲池大小可以让查询从缓冲池访问而不是通过磁盘I/O访问。通过调整系统变量innodb_flush_method来调整清除缓冲的指标使其达到最佳水平。

MySQL的内存分配

在为MySQL分配足够的内存之前，请考虑不同领域对MySQL的内存需求。要考虑的关键领域是：并发连接——对于大量并发连接，排序和临时表将需要大量内存。在撰写本文时，对于处理3000+并发连接的数据库，16GB到32GB的RAM是足够的。

内存碎片可以消耗大约10%或更多的内存。像innodb_buffer_pool_size、key_buffer_size、query_cache_size等缓存和缓冲区要消耗大约80%的已分配内存。

日常维护

定期检查慢的查询日志并优化查询机制以有效使用缓存来减少磁盘I/O。优化它们，以扫描最少的行数，而不是进行全表扫描。

其他可以帮助DBA检查和分析性能的日志包括：错误日志、常规查询日志、二进制日志、DDL日志(元数据日志)。

定期刷新缓存和缓冲区以降低碎片化。使用OPTIMIZETABLE语句重新组织表并压缩任何可能被浪费的空间。

---