我把每日股票成交明细的 csv 文件，导入到 mysql 里，结果数据库占硬盘过大怎么处理..

資深大佬 : blueaurora 7

我从淘宝上买了每天的股票成交明细文件，每支股票一天的成交明细就是一个 csv，一天就是 3800 多个 csv （沪深股票总数。打成 7z 压缩包，就是 400M 左右。一个月 30 天的话，也就是 12G 左右。我觉得 csv 麻烦，就想把这些数据写到 mysql 里

我用 python 的 sqlalchemy 从 csv 里先读出 DataFrame，再把成交股数改为成交手数，再 dataFrame.toSql 写到 mysql 里。但没想到 mysql 里一天的数据，也就是对应压缩包 400M 的数据，竟然占了 27G.. 我看一个 csv 的内容，到 mysql 里是 10M 左右..我也不知道还有什么乱七八糟的，怎么这么大

我这个 csv 的行首，就是下边这些了，一般股票，也就是一个 csv 也就 3 万列: TranID Time Price Volume SaleOrderVolume BuyOrderVolume Type SaleOrderID SaleOrderPrice BuyOrderID BuyOrderPrice

我从 sqlalchemy 打印出来的 sql 语句看 TranID 、SaleOrderID 、BuyOrderID ，都是 BigInteger

而 SaleOrderVolume BuyOrderVolume Price SaleOrderPrice BuyOrderPrice 因为有小数，从 sqlalchemy 打印出来的 sql 语句看都是 Float(53)，应该转成 double 了

我觉得这个类型不是影响数据库占硬盘大小的关键问题吧？我是个 mysql 新手，想问问这事怎么优化, 我希望的是同样数据量 mysql 占硬盘比 csv 还小，哪知道大了这么多倍

大佬有話說 (37)

資深大佬 : xyjincan

设计该表为压缩表
Mysql 开发手册中指出，“In particular, compressed tables use less disk space and so require less disk I/O to read and write the data. Compression is available for all kinds of workloads with InnoDB tables, and for read-only MyISAM tables.”
————————————————

关闭日志
資深大佬 : encro

— 查看那张表占用空间大

USE information_schema;

SELECT
TABLE_SCHEMA,
TABLE_NAME,
DATA_LENGTH,
INDEX_LENGTH
FROM
TABLES
GROUP BY
TABLE_SCHEMA
ORDER BY
DATA_LENGTH DESC;

— 修改表采用压缩

USE mydb;

ALTER TABLE mytable ROW_FORMAT = DYNAMIC;

OPTIMIZE TABLE mytable;

如果没有 DYNAMIC，那么采用 COMPRESSED 也可以

— 修改表采用 tokudb （需要安装 tokudb 引擎）

ALTER TABLE `mytable`
ENGINE=tokudb;

数据可以共享下不？
資深大佬 : encro

还有就是修改字段长度
資深大佬 : felixcode

可能不是数据文件占用的，是日志文件占用的，先找下是什么文件占用的空间吧
資深大佬 : encro

希望占用比 csv 小是不可能的。采用 gbk 存？

ALTER TABLE `mytable`
DEFAULT CHARACTER SET=gbk,
資深大佬 : encro

mysql 日志爆满，删除日志文件，定时清理日志
https://my.oschina.net/magicalSam/blog/1143079

以上写进了我新鲜出炉的 Blog:

Mysql 查看以及优化表空间
https://c4ys.com/archives/2255
主資深大佬 : blueaurora

@encro
数据我在 http://www.sdata.vip 买的，200 块一年吧
网盘是 https://pan.baidu.com/s/1nAqB-fA4S9dz98znapSfNQ#list/path=%2F
pwd 是 ascii 十进制 105 112 112 100 ，也就是四个小写字母。
隔一段网盘密码就换
資深大佬 : imn1

分笔数据只能用服务器级机器
实际上个人拿分笔没太大用，因为个人通过券商联网购买，比起席位号机器购买是有延时的
除非预埋地雷单，否则抢不过人家

如果要做深度分析，还是备台强力机器吧
主資深大佬 : blueaurora

@encro 每个表就是 10M，3800 个表，那其实就是好几十 G 了。这表不能再小了？
主資深大佬 : blueaurora

@felixcode 同问
“每个表就是 10M，3800 个表，那其实就是好几十 G 了。这表不能再小了？”
主資深大佬 : blueaurora

现在就是一个表的 .ibd 文件，就是 10M 的样子。比如 600196.ibd ,有 14M
主資深大佬 : blueaurora

我没有开日志呢..
資深大佬 : fengyqf

数据库通常不会比 csv 小，除了数据还要存索引，都要空间；字符串型字段，如果固定长度的表，还会大量浪费空间。
資深大佬 : laminux29

你可以写个程序，每次查询时，先自动从 7z 解压，自动导入 mysql，然后再进行查询。查询完毕后，自动把 mysql 数据清空。这样就能解决数据库占硬盘过大的问题。
資深大佬 : yzwduck

如果是 mysql 新手的话，我觉得可以跳过 mysql，试试 xsv 这个工具，它能直接处理 csv 数据。
csv 体积大的话，可以用 xz/zstd 压缩一下。
資深大佬 : laqow

我能想到的直接存 csv 的 gz，写个 python 的接口，需要哪天再读哪天进数据库，数据库只维护关系表，不维护具体数据
資深大佬 : outoftimeerror

写 hive，日期做分区字段，格式选 parquet
資深大佬 : rockyou12

换 pg 试下，我现在就用 pg 分析日线周线，数据量应该比你的小但完全没碰到压力。或者考虑下 timescale ？这个是时序数据库，但基本还是 pg 用法，性能要强得多
資深大佬 : angryfish

要注意字段类型的设置
資深大佬 : ichao1214

场景不太适合，不如使用时直接读 csv 。
資深大佬 : Jackeriss

看下你字段类型和索引设置
資深大佬 : silentsee

分析场景，直接上 clickhouse
資深大佬 : felixcode

@blueaurora
要跟文本相差不大的话，那应该就差不多，mysql 不大清楚，pg 应该有数据压缩的功能或模块，我刚简单搜一下 postgresql data compression，还是能找出不少来的。
資深大佬 : hbolive

mysql 比 csv 小不太可能，但是你这也差太多了，看是不是字段不合理。。
資深大佬 : boyhailong

压缩
資深大佬 : QGabriel

能问问多钱买的吗?
資深大佬 : chenxytw

OLAP 场景，选一些列式存储吧….做这些的公司就没见过用 Mysql 的…..
主資深大佬 : blueaurora

@QGabriel 看 7
主資深大佬 : blueaurora

谢谢大伙，看来确实白，这场景应该不太适合用 mysql 。我先改字段+toku 试一下
資深大佬 : Jafee

@blueaurora #7 密码换过了？好像不对了。
資深大佬 : bnm965321

这个是数据仓库的应用场景，可以看看 AWS 的 RedShift 。
資深大佬 : kelvin_fly

这些数据应该也可以实时抓取。我本来也想程序做一下，后来感觉不如肉眼和手动操作好～
主資深大佬 : blueaurora

@kelvin_fly 这个数据是分笔真实成交，不是 3 秒或 1 秒的成交快照，实时抓取不到的，这也不是实时数据，当天下午 4 点左右出来的
資深大佬 : fiht

可以考虑用一下 clickhouse，自带压缩，兼容 SQL 语法，非常方便
主資深大佬 : blueaurora

@Jafee 目前还没有换啊..注意我给的是字母的十进制 ascii 码
資深大佬 : Jafee

@blueaurora 奇怪，当时怎么输入都不对，后来就可以了。谢谢！
資深大佬 : rnicrosoft

@blueaurora 分享被取消了