怎样控制select和insert在1毫秒内。

左大神在这 2009-12-14 08:41:39
有这样一个表mytable
A bigint(20) primary key.
B varchar(2000),
C varchar(500),
D tinyint(2).

表中有300万条记录。现在要select * from mytable where A=? 这样的语句处理时间小于1毫秒,insert,update操作也是很简单的insert mytable (A,B,C,D) values(?,?,?,?); update也是单表根据key更新。
我测试大部分时间都超过1毫秒了,偶然小于1毫秒,大家有什么优化方案没有,数据库是MYSQL.
我想了,更新和插入可以采取异步更新到数据库的方式,但是查询呢??

说明:如果同时把这些数据存在应用系统的内存,是可以解决的,但是耗费内存太大,而且不能持久保存,所以单纯这个方案否定了。

大家帮忙看看,谢谢了。
...全文
311 39 打赏 收藏 转发到动态 举报
写回复
用AI写文章
39 条回复
切换为时间正序
请发表友善的回复…
发表回复
左大神在这 2009-12-25
  • 打赏
  • 举报
回复
[Quote=引用 37 楼 lhj 的回复:]
另外楼主的业务为何需要先查询在插入呢。可否考虑直接插入如果存在就update呢,这样Mysql一个语句搞定:
insert .... ON DUPLICATE KEY UPDATE ....
[/Quote]
不错,我是查询出来 再更新,不需要查询出来再插入。
左大神在这 2009-12-25
  • 打赏
  • 举报
回复
[Quote=引用 36 楼 lhj 的回复:]
楼主的需求最好是用文件处理了,这样可以根据自己的实际情况进行C语言甚至汇编代码级别的优化。
如果用MySql,楼主可以尝试一下:
假设楼主的并发量不大的情况下
1,采用MyISAM引擎.
2,以硬盘空间换取时间,楼主的varchar字段能否给成固定长度的char字段。这样每行的长度固定,mysql处理时间上更快。
3,关闭QueryCache,因为你的表老修改,开QueryCache降低性能。
4,查看MYI文件大小,在内存中KEY_Buffer_Size大小一定要比MYI文件大。确保所有关于字段A的索引都能装入内存(估计300万记录,至少需要60M吧,楼主的硬件语序的话,设置256M能成?)
5,增加一个启动时运行的Sql脚本,在启动的时候就将索引load到内存。
6,考虑插入锁优先级比Select锁低。
7,Primary Key的优化,根据楼主A字段的值,查看是否有更好的优化方式,是采用Btree还是hash等。
[/Quote]
你讲得很有道理,看得出来你对MYSQL很精通哈。
lhj 2009-12-25
  • 打赏
  • 举报
回复
另外楼主的业务为何需要先查询在插入呢。可否考虑直接插入如果存在就update呢,这样Mysql一个语句搞定:
insert .... ON DUPLICATE KEY UPDATE ....
lhj 2009-12-25
  • 打赏
  • 举报
回复
楼主的需求最好是用文件处理了,这样可以根据自己的实际情况进行C语言甚至汇编代码级别的优化。
如果用MySql,楼主可以尝试一下:
假设楼主的并发量不大的情况下
1,采用MyISAM引擎.
2,以硬盘空间换取时间,楼主的varchar字段能否给成固定长度的char字段。这样每行的长度固定,mysql处理时间上更快。
3,关闭QueryCache,因为你的表老修改,开QueryCache降低性能。
4,查看MYI文件大小,在内存中KEY_Buffer_Size大小一定要比MYI文件大。确保所有关于字段A的索引都能装入内存(估计300万记录,至少需要60M吧,楼主的硬件语序的话,设置256M能成?)
5,增加一个启动时运行的Sql脚本,在启动的时候就将索引load到内存。
6,考虑插入锁优先级比Select锁低。
7,Primary Key的优化,根据楼主A字段的值,查看是否有更好的优化方式,是采用Btree还是hash等。
左大神在这 2009-12-18
  • 打赏
  • 举报
回复
[Quote=引用 34 楼 sunwch 的回复:]
像这么大的数据做数据更新和插入的时候估计没有更好的办法来解决,查询好说直接做索引就可以。期待答案中...
[/Quote]
目前在考虑读写文件处理。
sunwch 2009-12-18
  • 打赏
  • 举报
回复
像这么大的数据做数据更新和插入的时候估计没有更好的办法来解决,查询好说直接做索引就可以。期待答案中...
iisbsd 2009-12-17
  • 打赏
  • 举报
回复
搞几百个表,用key计算表的名字,这样每个表里面只有几万条记录(如果key是比较平均的话),时间就好控制了。

因为你所有的操作都是根据key来的,所以可以直接针对某个表操作,而且key是数值,做一个hash也很快(或者干脆取最后几位)。

如果将来要对所有的数据同时操作,可以考虑merge engine
wenjjing2lianee 2009-12-16
  • 打赏
  • 举报
回复
强.........
左大神在这 2009-12-15
  • 打赏
  • 举报
回复
尝试用写文件的方法看看是否可以实现。
maquan 2009-12-15
  • 打赏
  • 举报
回复
[Quote=引用 29 楼 chuan122345 的回复:]
就是不想用大内存才这么麻烦,要是有足够的内存,就不用考虑数据库了。主要想通过技术手段解决,而非硬件解决。
[/Quote]
只把 id 保存在内存里可以吗?300w 数据大概也就需要百十来M的内存而已。

如果可以的话,就自己实现一套管理查询算法,然后实际的数据体以文件的形式保存在磁盘上。当然要考虑查找/更新算法效率优化、读写冲突、IO缓存等等,基本上相当于把数据库的存储引擎和索引算法重新实现了一遍(简化版),hehe

理论上讲,这样肯定能做到比数据库的效率高。但要“确保1ms以内”说到底是不可靠的,毕竟你的操作系统就不是“实时操作系统”。
左大神在这 2009-12-14
  • 打赏
  • 举报
回复
navicat存储引擎--》navicat工具
左大神在这 2009-12-14
  • 打赏
  • 举报
回复
[Quote=引用 20 楼 shine333 的回复:]
引用 14 楼 chuan122345 的回复:
CPU每个时钟信号周期的单位一般都用纳秒表示的。1纳秒=1000000毫秒


那个没什么意义,1秒CPU周期再多,架不住做到事情多。
光遍历一遍“select * from mytable where A=100”这三十几个字符,可能就需要大概100个周期,这还不是解析SQL语句。


感觉,还是尽量使用CPU+内存,避免disk i/o。如果用索引的话,最好利用hash类型的索引,而不是btree(但不知道PK可不可以hash,貌似好像不可以)
[/Quote]
呵呵,我只知道MEMORY存储引擎用的是hash索引,所以速度快,我用navicat存储引擎建立索引,好像只有普通索引,唯一索引和全文索引,这几个索引类型选择。
shine333 2009-12-14
  • 打赏
  • 举报
回复
[Quote=引用 14 楼 chuan122345 的回复:]
CPU每个时钟信号周期的单位一般都用纳秒表示的。1纳秒=1000000毫秒
[/Quote]

那个没什么意义,1秒CPU周期再多,架不住做到事情多。
光遍历一遍“select * from mytable where A=100”这三十几个字符,可能就需要大概100个周期,这还不是解析SQL语句。


感觉,还是尽量使用CPU+内存,避免disk i/o。如果用索引的话,最好利用hash类型的索引,而不是btree(但不知道PK可不可以hash,貌似好像不可以)
平凡的思想者 2009-12-14
  • 打赏
  • 举报
回复
对mysql的性能我专门做过测试,请查看:
http://blog.csdn.net/forever_feng/archive/2009/10/16/4679233.aspx
ACMAIN_CHM 2009-12-14
  • 打赏
  • 举报
回复
[Quote]读文件,写文件的效率比数据库高多少?[/Quote]

比数据库高很多。 一个是直接通过操作系统操作磁盘IO,一个是提交个数据库系统,然后由数据库系统来操作操作系统写磁盘IO
这一点无需置疑。

当然也和你的代码效率有关。
shine333 2009-12-14
  • 打赏
  • 举报
回复
[Quote=引用 15 楼 chuan122345 的回复:]
引用 13 楼 acmain_chm 的回复:
1ms 的确比较难以控制。

硬件上能不能想点办法,比如用高端的服务器。


一般如果是工控实时系统,很少直接用数据库的,一般是前置上位机来处理,把数据先写入文件,然后后端再慢慢插入到数据库中。

读文件,写文件的效率比数据库高多少? 我记得以前测试好像跟DB差不多,准备尝试下,因为DB其实也是写文件嘛。
[/Quote]
你没听懂,人家是让你启动的时候读一遍、关闭的时候写一遍,跟每次都有Disk I/O操作有本质不同
左大神在这 2009-12-14
  • 打赏
  • 举报
回复
关于时间的最小单位,可以参考:
http://blog.csdn.net/chuan122345/archive/2009/12/11/4985463.aspx

1秒 =1000000000000000飞秒 =1000000000000皮秒 = 1000000000纳秒 = 1000000微秒 = 1000毫秒
1秒 = 1000000000000皮秒 = 1000000000纳秒 = 1000000微秒 = 1000毫秒
1秒 = 1000000000纳秒 = 1000000微秒 = 1000毫秒
1秒 = 1000000微秒 = 1000毫秒
1秒 = 1000毫秒


左大神在这 2009-12-14
  • 打赏
  • 举报
回复
[Quote=引用 13 楼 acmain_chm 的回复:]
1ms 的确比较难以控制。

硬件上能不能想点办法,比如用高端的服务器。


一般如果是工控实时系统,很少直接用数据库的,一般是前置上位机来处理,把数据先写入文件,然后后端再慢慢插入到数据库中。
[/Quote]
读文件,写文件的效率比数据库高多少? 我记得以前测试好像跟DB差不多,准备尝试下,因为DB其实也是写文件嘛。
左大神在这 2009-12-14
  • 打赏
  • 举报
回复
CPU每个时钟信号周期的单位一般都用纳秒表示的。1纳秒=1000000毫秒
ACMAIN_CHM 2009-12-14
  • 打赏
  • 举报
回复
1ms 的确比较难以控制。

硬件上能不能想点办法,比如用高端的服务器。


一般如果是工控实时系统,很少直接用数据库的,一般是前置上位机来处理,把数据先写入文件,然后后端再慢慢插入到数据库中。
加载更多回复(19)

56,677

社区成员

发帖
与我相关
我的任务
社区描述
MySQL相关内容讨论专区
社区管理员
  • MySQL
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧