s*******o
发帖数: 392 | 1 金融数据data，tick的，大概从2005年9月到2010年9月份的，算起来大概有46million
行，列的结构很简单，就是时间 yyyy:mm:dd 00:00:00,这样的，然后有两列是买卖的
price。
有些天的tick不全，公司给的是直接的sql的dumpfile，导入后，尝试如下命令
select price from eur_usd where date(time) between 20080101 00:00:00 AND
20080102 00:00:00。
大概有19000行数据，可是花了我24秒钟读取出来，我怀疑是不是mysql走了一遍整个
46million的表格啊。大家知道的，金融数据严格按照时间排列的，所以不会说这里找
一个数据，哪里找个数据的，应该就是一气读下来连着几万行就好了。这么慢，我强烈
怀疑它mysql给我整个table去filter去了
有什么办法啊！！！谢谢 |
a*******s
发帖数: 324 | 2 MySQL又不是你肚子里的蛔虫，怎么会知道你的数据是按时间排的， 没加index，当然
全扫描，要不漏啦数据，你又该抱怨拉。
46million
【在 s*******o 的大作中提到】
: 金融数据data，tick的，大概从2005年9月到2010年9月份的，算起来大概有46million
: 行，列的结构很简单，就是时间 yyyy:mm:dd 00:00:00,这样的，然后有两列是买卖的
: price。
: 有些天的tick不全，公司给的是直接的sql的dumpfile，导入后，尝试如下命令
: select price from eur_usd where date(time) between 20080101 00:00:00 AND
: 20080102 00:00:00。
: 大概有19000行数据，可是花了我24秒钟读取出来，我怀疑是不是mysql走了一遍整个
: 46million的表格啊。大家知道的，金融数据严格按照时间排列的，所以不会说这里找
: 一个数据，哪里找个数据的，应该就是一气读下来连着几万行就好了。这么慢，我强烈
: 怀疑它mysql给我整个table去filter去了
|
s*******o
发帖数: 392 | 3
对，你说的没错，不过我没什么经验，所以猜测他是全表给我走了一遍。唉，不做不知
道，做了才发现确实，relational的表格不适合大规模的tick。怪不得那么多人要用
binary file，column data去存。
【在 a*******s 的大作中提到】
: MySQL又不是你肚子里的蛔虫，怎么会知道你的数据是按时间排的， 没加index，当然
: 全扫描，要不漏啦数据，你又该抱怨拉。
:
: 46million
|
s*******o
发帖数: 392 | |
s*******o
发帖数: 392 | 5 人气太差，人也不热心，还是去问老外吧，后悔用中文写这么多 |
s*******o
发帖数: 392 | 6 金融数据data，tick的，大概从2005年9月到2010年9月份的，算起来大概有46million
行，列的结构很简单，就是时间 yyyy:mm:dd 00:00:00,这样的，然后有两列是买卖的
price。
有些天的tick不全，公司给的是直接的sql的dumpfile，导入后，尝试如下命令
select price from eur_usd where date(time) between 20080101 00:00:00 AND
20080102 00:00:00。
大概有19000行数据，可是花了我24秒钟读取出来，我怀疑是不是mysql走了一遍整个
46million的表格啊。大家知道的，金融数据严格按照时间排列的，所以不会说这里找
一个数据，哪里找个数据的，应该就是一气读下来连着几万行就好了。这么慢，我强烈
怀疑它mysql给我整个table去filter去了
有什么办法啊！！！谢谢 |
a*******s
发帖数: 324 | 7 MySQL又不是你肚子里的蛔虫，怎么会知道你的数据是按时间排的， 没加index，当然
全扫描，要不漏啦数据，你又该抱怨拉。
46million
【在 s*******o 的大作中提到】
: 金融数据data，tick的，大概从2005年9月到2010年9月份的，算起来大概有46million
: 行，列的结构很简单，就是时间 yyyy:mm:dd 00:00:00,这样的，然后有两列是买卖的
: price。
: 有些天的tick不全，公司给的是直接的sql的dumpfile，导入后，尝试如下命令
: select price from eur_usd where date(time) between 20080101 00:00:00 AND
: 20080102 00:00:00。
: 大概有19000行数据，可是花了我24秒钟读取出来，我怀疑是不是mysql走了一遍整个
: 46million的表格啊。大家知道的，金融数据严格按照时间排列的，所以不会说这里找
: 一个数据，哪里找个数据的，应该就是一气读下来连着几万行就好了。这么慢，我强烈
: 怀疑它mysql给我整个table去filter去了
|
s*******o
发帖数: 392 | 8
对，你说的没错，不过我没什么经验，所以猜测他是全表给我走了一遍。唉，不做不知
道，做了才发现确实，relational的表格不适合大规模的tick。怪不得那么多人要用
binary file，column data去存。
【在 a*******s 的大作中提到】
: MySQL又不是你肚子里的蛔虫，怎么会知道你的数据是按时间排的， 没加index，当然
: 全扫描，要不漏啦数据，你又该抱怨拉。
:
: 46million
|
s*******o
发帖数: 392 | |
s*******o
发帖数: 392 | 10 人气太差，人也不热心，还是去问老外吧，后悔用中文写这么多 |
|
|
c*****d
发帖数: 6045 | 11 ambitious已经说的很清楚了，没有Index就只能全表扫描
解决方法就是在时间字段上创建index
你这样的需求，50 million行的数据relational db轻松搞定
根本用不到binary file
这里就是一个论坛，热心人很多，但是没人有义务帮你，不管是老中还是老外
我也挺后悔用中文写这么多 |
g***l
发帖数: 18555 | 12 MYSQL不会因为你是金融数据就给你自动排序的 |
y****w
发帖数: 3747 | 13 基本的index有没有，干嘛在predicate上用函数，直接用很麻烦么。
类似的问题：为啥oracle这么差？为啥db2跑不快？为啥sql server这么笨？再说大周末的，
【在 s*******o 的大作中提到】
: 人气太差，人也不热心，还是去问老外吧，后悔用中文写这么多
|
B*****g
发帖数: 34098 | 14 组里那个发文章的咋一看我还以为是你
【在 y****w 的大作中提到】
: 基本的index有没有，干嘛在predicate上用函数，直接用很麻烦么。
: 类似的问题：为啥oracle这么差？为啥db2跑不快？为啥sql server这么笨？再说大周末的，
|
y****w
发帖数: 3747 | 15 没，我是比较懒的。我现阶段工作也不是想稳定下来的，没心情；再说找工作也靠不住这个，公共媒体发东西除非有深度且能坚持，不然这影响力也搞不定没绿卡:)
倒是想起来了我需要拉票，前阵子参加了一个db2的活动，现在要各自拉票，来源不限制，好像马上要到期了。我上次说ppt超时了，嘴不利落。站内你链接。
【在 B*****g 的大作中提到】
: 组里那个发文章的咋一看我还以为是你
|
s*******o
发帖数: 392 | |
