非壓縮表
Ⅰ 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 壓縮表的優勢
- 1.4 壓縮表的缺陷
- 1.5 MySQL 支持的壓縮演算法
壓縮表的優點非常明顯，佔用磁碟空間小！由於佔用空間小，從磁碟置換到內存以及之後經過網路傳輸都非常節省資源。
簡單來講：節省磁碟 IO，減少網路 IO。
當然壓縮表也有缺點，壓縮表的寫入（INSERT,UPDATE,DELETE）比普通表要消耗更多的 CPU 資源。
壓縮表的寫入涉及到解壓數據，更新數據，再壓縮數據，比普通表多了解壓和再壓縮兩個步驟，壓縮和解壓縮需要消耗一定的 CPU 資源。所以需要選擇一個比較優化的壓縮演算法。
這塊是 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類型壓縮率會低些。