非压缩表

Ⅰ mysql数据库引擎innodb的主索引文件和表文件分开吗如果不分开，那怎么查询

innodb的主索引文件和表文件没有分开，他们在同一个表空间。

Ⅱ myisam和innodb索引实现的不同

MyISAM和和和和InnoDB比较

MyISAM:这个是默认类型,它是基于传统的ISAM类型,ISAM是Indexed Sequential Access Method (有索引的 顺序访问方法) 的缩写,它是存储记录和文件的标准方法.与其他存储引擎比较,MyISAM具有检查和修复表格的大多数工具. MyISAM表格可以被压缩,而且它们支持全文搜索.它们不是事务安全的,而且也不支持外键。如果事物回滚将造成不完全回滚，不具有原子性。如果执行大量 的SELECT，MyISAM是更好的选择。

InnoDB:这种类型是事务安全的.它与BDB类型具有相同的特性,它们还支持外键.InnoDB表格速度很快.具有比BDB还丰富的特性,因此如果需要一个事务安全的存储引擎,建议使用它.如果你的数据执行大量的INSERT或UPDATE,出于性能方面的考虑，应该使用InnoDB表, 对于支持事物的InnoDB类型的表，影响速度的主要原因是AUTOCOMMIT默认设置是打开的，而且程序没有显式调用BEGIN 开始事务，导致每插入一条都自动Commit，严重影响了速度。可以在执行sql前调用begin，多条sql形成一个事物（即使autocommit打 开也可以），将大大提高性能

Ⅲ mysql中myisam，innodb和memory三个存储引擎的区别

1、区别：
1） MyISAM管理非事务表。提供高速存储和检索，以及全文搜索能力。MyISAM在所有MySQL配置里被支持，是默认的存储引擎，除非配置MySQL默认使用另外一个引擎。
2）MEMORY存储引擎提供“内存中”表。MERGE存储引擎允许集合将被处理同样的MyISAM表作为一个单独的表。就像MyISAM一样，MEMORY和MERGE存储引擎处理非事务表，这两个引擎也都被默认包含在MySQL中。
注释：MEMORY存储引擎正式地被确定为HEAP引擎。
3）InnoDB和存储引擎提供事务安全表，默认被包括在所 有MySQL 5.1二进制分发版里，可以按照喜好通过配置MySQL来允许或禁止任一引擎。

2、功能点简介
1）MyISAM存储引擎
MyISAM存储引擎不支持事务，不支持行级锁，只支持并发插入的表锁，主要用于高负载的select。
myisam类型的表支持三种不同的存储结构：静态型、动态型、压缩型。
（1）静态型：就是定义的表列的大小是固定（即不含有：xblob、xtext、varchar等长度可变的数据类型），这样mysql就会自动使用静态myisam格式。
使用静态格式的表的性能比较高，因为在维护和访问的时候以预定格式存储数据时需要的开销很低。但是这高性能是有空间换来的，因为在定义的时候是固定的，所以不管列中的值有多大，都会以最大值为准，占据了整个空间。
（2）动态型：如果列（即使只有一列）定义为动态的（xblob, xtext, varchar等数据类型），这时myisam就自动使用动态型，虽然动态型的表占用了比静态型表较少的空间，但带来了性能的降低，因为如果某个字段的内容发生改变则其位置很可能需要移动，这样就会导致碎片的产生。随着数据变化的怎多，碎片就会增加，数据访问性能就会相应的降低。
（3）压缩型：如果在这个数据库中创建的是在整个生命周期内只读的表，则这种情况就是用myisam的压缩型表来减少空间的占用。

2）MEMORY存储引擎：
（1）memory存储引擎相比前面的一些存储引擎，有点不一样，其使用存储在内从中的数据来创建表，而且所有的数据也都存储在内存中。
（2）每个基于memory存储引擎的表实际对应一个磁盘文件，该文件的文件名和表名是相同的，类型为.frm。该文件只存储表的结构，而其数据文件，都是存储在内存中，这样有利于对数据的快速处理，提高整个表的处理能力。
（3）memory存储引擎默认使用哈希（HASH）索引，其速度比使用B-+Tree型要快，如果读者希望使用B树型，则在创建的时候可以引用。
（4）memory存储引擎文件数据都存储在内存中，如果mysqld进程发生异常，重启或关闭机器这些数据都会消失。所以memory存储引擎中的表的生命周期很短，一般只使用一次。

3）innoDB存储引擎：

（1） innodb存储引擎该mysql表提供了事务，回滚以及系统崩溃修复能力和多版本迸发控制的事务的安全。
（2）innodb支持自增长列（auto_increment）,自增长列的值不能为空，如果在使用的时候为空的话怎会进行自动存现有的值开始增值，如果有但是比现在的还大，则就保存这个值。
（3）innodb存储引擎支持外键（foreign key） ,外键所在的表称为子表而所依赖的表称为父表。
（4）innodb存储引擎最重要的是支持事务，以及事务相关联功能。
（5）innodb存储引擎支持mvcc的行级锁。

Ⅳ 8086汇编中的AAA指令有什么作用什么是非压缩的BCD格式

执行后的结果为 AH=01，AL=05

非压缩BCD表示8位表示十进制数，而压缩BCD码8位可以表求两位十进制数

例如 12的非压缩BCD码为AX=0102H ，而压缩BCD码为AL=12H

AAA是将AL中的和调整成有效的非压缩的十进制数

Ⅳ 如何压缩word中的表格数据急急急~在线等~

方法一、选中整个表格，点击“格式”菜单中的字号，将字体缩小，整个表格就会缩小。
方法二、将光标放到表达任意两行之间时，光标会变成一个上下相对的双箭头，按住鼠标左键向上拖动，缩小行间距。如果想每行的高度一致，选中整个表格，在上面单击右键，在弹出的菜单中左键单击“平均分布各行”即可将每行高度调整一致。
方法三、点击“文件”菜单，点击“页面设置”，在弹出的“页面设置对话框”中，将“页边距”中的上下边距的数字缩小，必要时在“版式”标签下，将“页眉页脚”的数值也缩小。
以上方法可同时使用，直到压缩到一页为止。

Ⅵ mysql建立数据库表的时候TYPE=InnoDB有什么作用

TYPE=InnoDB 表示数据表的引擎类型为innoDB
innodb存储引擎：[/color][/b] 面向oltp(online transaction processing)、行锁、支持外键、非锁定读、默认采用repeaable级别（可重复读）通过next-keylocking策略避免幻读、插入缓冲、二次写、自适应哈希索引、预读

Ⅶ oracle11g怎么建立压缩表

在数据量变的很大的情况下，可以考虑表压缩，减少磁盘的存储，减少buffer cache的消耗，加快查询的速度，压缩需要在数据加载和dml的时候消耗一些cpu.表压缩对于应用是透明的。

你可以在表空间，表或分区级别指定压缩，如果在表空间级别指定压缩，那么这个表空间中的所有表默认都是压缩的。

压缩会发生在数据插入，更新或批量加载到表时。有几种类型的压缩。基本的，oltp的，dss的，归档的。他们的cpu消耗见文档。

当使用基本压缩，数据仓库压缩，或归档压缩的时候，压缩仅仅是在批量加载到一个表的时候发生。当你使用了oltp压缩，压缩发生在数据插入，更新，批量加载。

如果你使用了alter table命令让表启用压缩，那么对于已存在的数据是不受影响的，只有在启用压缩后的插入，或更新会受影响。也可以使用ALTER TABLE…NOCOMPRESS将一个表设置成非压缩，对于已经的压缩的表是没有影响的，压缩的数据还是压缩的，只是新插入的数据是不被压缩。

创建一个oltp压缩类型的表
CREATE TABLE orders … COMPRESS FOR OLTP;

如果你不指定压缩的类型，那么默认的情况下是基本压缩类型。下面的2个语句是等价的。
CREATE TABLE sales_history … COMPRESS BASIC;

CREATE TABLE sales_history … COMPRESS;

下面的表是一个数据仓库压缩类型的表，对于经常查询，并且没有dml的表适用。
CREATE TABLE sales_history … COMPRESS FOR QUERY;

创建一个归档压缩类型的表
CREATE TABLE sales_history … COMPRESS FOR ARCHIVE;

表可以包含压缩和非压缩的分区，并且不同的分区的压缩的类型可以是不同的，如果在分区上指定的压缩的类型与表上指定的压缩的类型不同，那么分区上的优先。

查看表是否是压缩的，及分区是否是压缩的。
SQL> SELECT table_name, compression, compress_for FROM user_tables;

SELECT table_name, partition_name, compression,compress_for
FROM user_tab_partitions;

查看表中的行是什么压缩类型
SELECT DECODE(DBMS_COMPRESSION.GET_COMPRESSION_TYPE(
ownname => ‘HR’,
tabname => ‘EMPLOYEES’,
row_id => ‘AAAVEIAAGAAAABTAAD’),
1, ‘No Compression’,
2, ‘Basic or OLTP Compression’,
4, ‘Hybrid Columnar Compression for Query High’,
8, ‘Hybrid Columnar Compression for Query Low’,
16, ‘Hybrid Columnar Compression for Archive High’,
32, ‘Hybrid Columnar Compression for Archive Low’,
‘Unknown Compression Type’) compression_type
FROM DUAL;

修改压缩的级别

如果表是分区表，使用在线重定义可以修改表的压缩级别。如果表是分分区表，那么可以使用alter table ..move.. compress for语句修改表的压缩级别，这个语句会阻塞dml操作。

对于压缩表的限制：
1基本压缩，你不能为添加的列指定默认的值。删除列是不被支持的。
2oltp压缩，如果要添加一个带默认值的列，那么需要指定not null，可以删除列，但是数据只是在内部做了一个不被使用的标记而已。

3在线段收缩是不被支持的。

4上面的压缩的方式不适合于lobs类型，他们有自己的压缩方式。

5基本压缩类型的表的pct_free参数自动的设置成0.

在上面的描述中可以看到对于基本类型的压缩，没有使用直接路径插入的行及更新的行是不会被压缩的。对于我们的oltp系统基本是没有用处的，只测试下oltp的压缩方式，这种方式对于没有使用直接路径插入的行及被更新的行都会压缩。

SQL> select count(*) from xyu2;

COUNT(*)

22096384

SQL> set serveroutput on
SQL> exec show_space(‘BAIXYU2’,’T’,’AUTO’);
Total Blocks……………………….334336
Total Bytes………………………..2738880512
Unused Blocks………………………1916
Unused Bytes……………………….15695872
Last Used Ext FileId………………..4
Last Used Ext BlockId……………….671872
Last Used Block…………………….6276

CREATE TABLE xyu3 COMPRESS FOR OLTP as select * from xyu2;

SQL> exec show_space(‘BAIXYU3’,’T’,’AUTO’);
Total Blocks……………………….107520
Total Bytes………………………..880803840
Unused Blocks………………………112
Unused Bytes……………………….917504
Last Used Ext FileId………………..4
Last Used Ext BlockId……………….116224
Last Used Block…………………….912

看到使用的块由33w下降到10w。压缩效果还是不错，但是是否使用还要结果上面的限制来根据实际情况评估。

Ⅷ 如何压缩Mysql数据库

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

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'blocksize'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表压缩和整理如下：
633M -rw-rw---- 1 mysql mysql 632M Oct 25 17:51 url_comment_0.ibd 12K -rw-rw---- 1 mysql mysql 8.7K Oct 25 18:16 url_comment_0.frm 178M -rw-rw---- 1 mysql mysql 178M Oct 25 18:53 url_comment_0.MYD 99M -rw-rw---- 1 mysql mysql 98M Oct 25 18:53 url_comment_0.MYI
结论:由上面数据可知innodb plugin能有效压缩innodb数据文件,近50%,另外相同的情况下使用MyISAM表也可较大的减少数据大小(178+99<633M).
当然实际的压缩比例和表的结构等有关,如字段为varchar会有较大的压缩比,而int类型压缩率会低些。