本文主要通过批量与非批量对比操作的方式介绍MongoDB的bulkWrite()方法的使用.顺带与关系型数据库MySQL进行对比,比较这两种不同类型数据库的效率.如果只是想学习bulkWrite()的使用的看第一部分就行. 测试环境:win7旗舰版.16G内存.i3处理器.MongoDB3.0.2.mysql5.0 一.MongoDB批量操作 MongoDB对数据的操作分为Read Operations和Write Operations,Read Operations包含查询操作,Write O

1,表设计一定要优化,冗余数据最少,少用连接查询.如果在实际应用中,使用了极其复杂的连接,子查询,则数据表的设计得要重新考虑了. 2,尽量用char而不是varchar,因为固定长度得string用起来更快.在当今硬盘容量越来越大的情况下,牺牲点存储空间而换得查询速度得提升是值得的. 3,通过简化权限来提高查询速度.如果一个查询之前要执行很多权限验证,则查询速度会慢下来,不妨试着在mysql中用root登录与用你新建的有权限控制的用户登录的速度,就可以看出来了,root登录,一下子就进入了,而普

MySQL查询缓存详解(总结) 一.总结 一句话总结: mysql查询缓存还是可以用用试一试,但是更推荐分布式,比如redis/memcache之流,将数据库中查询的数据和查询语句以键值对的方式存进分布式中 1.MySQL查询缓存 原理? SELECT语句以及该语句的结果集组成的键值对 MySQL Query Cache是用来缓存我们所执行的SELECT语句以及该语句的结果集,MySql在实现Query Cache的具体技术细节上类似典型的KV存储,就是将SELECT语句和该查询语句的结果集做了

MySQL凭借着出色的性能.低廉的成本.丰富的资源,已经成为绝大多数互联网公司的首选关系型数据库.虽然性能出色,但所谓“好马配好鞍”,如何能够更 好的使用它,已经成为开发工程师的必修课,我们经常会从职位描述上看到诸如“精通MySQL”.“SQL语句优化”.“了解数据库原理”等要求.我们知道 一般的应用系统,读写比例在10:1左右,而且插入操作和一般的更新操作很少出现性能问题,遇到最多的,也是最容易出问题的,还是一些复杂的查询操作,所 以查询语句的优化显然是重中之重. 本人从13年7月份起,一直在

查询的原理 在一个查询中常包含下述子句: 1.select,2.distinct,3.join,4.on,5.from,6.where,7.having,8.group by,9.order by,10.limit 在查询执行过程中,每个子句按照一定的顺序被执行,每个子句被执行时都会产生一张虚拟表,只有最后一步生成的虚拟表才会返回给用户. 我们用实际的例子来讲解下查询的执行过程,先准备以下两张表: create table t_student( id bigint(20) not null au

一.数据库的优化 1.优化索引.SQL 语句.分析慢查询: 2.设计表的时候严格根据数据库的设计范式来设计数据库: 3.使用缓存,把经常访问到的数据而且不需要经常变化的数据放在缓存中,能节约磁盘IO: 4.优化硬件:采用SSD,使用磁盘队列技术(RAID0,RAID1,RDID5)等: 5.采用MySQL 内部自带的表分区技术,把数据分层不同的文件,能够提高磁盘的读取效率: 6.垂直分表:把一些不经常读的数据放在一张表里,节约磁盘I/O: 7.主从分离读写:采用主从复制把数据库的读操作和写入操作

OR.in和union all 查询效率到底哪个快. 网上很多的声音都是说union all 快于 or.in,因为or.in会导致全表扫描,他们给出了很多的实例. 但真的union all真的快于or.in?本文就是采用实际的实例来探讨到底是它们之间的效率. 1:创建表,插入数据.数据量为1千万[要不效果不明显]. drop table if EXISTS BT; create table BT( ID int(10) NOT NUll, VName varchar(20) DEFAULT '

索引的概念 索引是一种特殊的文件(InnoDB数据表上的索引是表空间的一个组成部分),它们包含着对数据表里所有记录的引用指针.更通俗的说,数据库索引好比是一本书前面的目录,能加快数据库的查询速度.在没有索引的情况下,数据库会遍历全部数据后选择符合条件的:而有了相应的索引之后,数据库会直接在索引中查找符合条件的选项.如果我们把SQL语句换成"SELECT * FROM 表名 WHERE id=2000000",那么你是希望数据库按照顺序读取完200万行数据以后给你结果还是直接在索引中定位

mysql in 子查询 效率慢 优化(转) 现在的CMS系统.博客系统.BBS等都喜欢使用标签tag作交叉链接,因此我也尝鲜用了下.但用了后发现我想查询某个tag的文章列表时速度很慢,达到5秒之久!百思不解(后来终于解决),我的表结构是下面这样的,文章只有690篇. 文章表article(id,title,content)标签表tag(tid,tag_name)标签文章中间表article_tag(id,tag_id,article_id)其中有个标签的tid是135,我帮查询标签tid是13

> 参考的优秀文章 优化LIMIT分页--<高性能MySQL>(电子工业出版社) > 场景描述 遇到一个场景:查询排序后的结果集较大,我们采用分页显示,每页显示20条记录,但是查询效率还是不尽理想. 结果,采用以下两个手段优化效率: 1.对排序的字段加上索引(普通索引,即BTREE),加了索引后,普通查询的效率加快了,但偏移量大的数据(比如排序靠后的数据)查询还是较慢. 2.借鉴<高性能MySQL>的手段,减少扫描范围.延迟关联,偏移量大的数据查询效率也得到优化. &g

[size=5][color=Red]提高MySQL数据库查询效率的几个技巧(转)[/color][/size]      MySQL由于它本身的小巧和操作的高效, 在数据库应用中越来越多的被采用.我在开发一个P2P应用的时候曾经使用MySQL来保存P2P节点,由于P2P的应用中,结点数动辄上万个,而且节点变化频繁,因此一定要保持查询和插入的高效.以下是我在使用过程中做的提高效率的三个有效的尝试. l 使用statement进行绑定查询 使用statement可以提前构建查询语法树,在查询时不再

前因:项目一直使用的是PageHelper实现分页功能,项目前期数据量较少一直没有什么问题.随着业务扩增,数据库扩增PageHelper出现了明显的性能问题.几十万甚至上百万的单表数据查询性能缓慢,需要几秒乃至十几秒的查询时间.故此特地研究了一下PageHelper源码,查找PageHelper分页的实现方式. 一段较为简单的查询,跟随debug开始源码探寻之旅. public ResultContent select(Integer id) { Page<Test> blogPage = P

在实际项目中,当MySQL表的数据达到百万级别时候,普通查询效率直线下降,而且当使用的where条件较多,其查询效率是让人无法容忍的.假如一个taobao订单查询详情要几十秒,可想而知的用户体验是多差. 查询效率慢的原因:1:没有加索引或者索引失效 where条件使用如下语句会索引失效:null.!=.<>.or连接.in(非要使用,可用关键字exist替代)和not in.'%abc%':使用参数:num=@num.表达式操作:where num/2=100.函数操作:where subst

OR.in和union all 查询效率到底哪个快. 网上很多的声音都是说union all 快于 or.in,因为or.in会导致全表扫描,他们给出了很多的实例. 但真的union all真的快于or.in?本文就是采用实际的实例来探讨到底是它们之间的效率. 1:创建表,插入数据.数据量为1千万[要不效果不明显]. drop table if EXISTS BT; create table BT( ID int(10) NOT NUll, VName varchar(20) DEFAULT '

mysql 中合并查询结果union用法 or.in与union all 的查询效率 (2016-05-09 11:18:23) 转载▼ 标签: mysql union or in 分类: mysql 问题一 mysql 中合并查询结果union用法 今天来写写union的用法及一些需要注意的. union:联合的意思,即把两次或多次查询结果合并起来. 要求:两次查询的列数必须一致 推荐:列的类型可以不一样,但推荐查询的每一列,想对应的类型以一样 可以来自多张表的数据:多次sql语句取出的列名可

在数据库设计的时候,我们经常会需要设计时间字段,在MYSQL中,时间字段可以使用int.timestamp.datetime三种类型来存储,那么这三种类型哪一种用来存储时间性能比较高,效率好呢?飘易就这个问题,来一个实践出真知吧. MYSQL版本号:5.5.19 建立表: CREATE TABLE IF NOT EXISTS `datetime_test` ( `id` int(11) NOT NULL, `d_int` int(11) NOT NULL DEFAULT '', `d_times

1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如: select id from t where num is null 可以在num上设置默认值0,确保表中num列没有null值,然后这样查询: select id from t where num=0 3.应尽量避免在 where 子句中使用!=或<>操作符,否则将引擎放

看了好多资料都说 varchar(size) 可变长度的字符值,节省空间,查询效率低 char(size) 固定长度的字符值,浪费空间,查询效率高 但是实际测试  char(100)   varchar(100)   300W条数据 从查询方面的角度来说,还是varchar毕竟靠谱 查询效率(在没有使用索引的情况下):   varchar的字段查询要比char快 通过对比  char100 需要查询时间1.10s   而varchar100 需要时间是973ms  欢迎大家指正!!

1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如: select id from t where num is null 可以在num上设置默认值0,确保表中num列没有null值,然后这样查询: select id from t where num=0 3.应尽量避免在 where 子句中使用!=或<>操作符,否则将引擎放

1.直接使用数据库提供的SQL语句 limit M ,N SELECT * from message limit 0 , 10 ; -- 0.044 SELECT * from message limit 100 , 10 ; -- 0.084 SELECT * from message limit 1000 , 10 ; -- 0.087 SELECT * from message limit 10000 , 10 ; -- 0.102 SELECT * from message limit

开发经常遇到分页查询的需求,但是当翻页过多的时候,就会产生深分页,导致查询效率急剧下降. 有没有什么办法,能解决深分页的问题呢? 本文总结了三种优化方案,查询效率直接提升10倍,一起学习一下. 1. 准备数据 先创建一张用户表,只在create_time字段上加索引: CREATE TABLE `user` ( `id` int NOT NULL AUTO_INCREMENT COMMENT '主键', `name` varchar(255) DEFAULT NULL COMMENT '姓名',