1.表定义 (1)如果字符串字段是经常需要用到的,可以冗余,否则不要冗余 (2)经常需要作为where的查询条件的字段,可以建索引:但是过多的索引会影响写入时的性能 (3)合理定义字段的数据类型 (4)分离存放附件或者大(超)文本的表 (5)字段数据类型尽可能使用更小的长度 2.在sql中 (1)减少*的使用 (2)避免使用游标,select中的逻辑 可以使用“ case 加 自定义函数”代替 (3)在使用join前,先把将要连接的集合用现有的条件缩小,然后再连接 (4)减少in的使用,尤其是

业务扩展字段在数据库中经常会使用json格式的数据来存储,这就涉及到一个头疼的问题,假设要使用扩展字段里的某个值作为查询条件怎么办,原来PostgreSQL本身就支持这种查询方式. 例子:假设业务扩展字段ext_data存的json格式如下: 我们需要查询扩展字段中extInfo.userType=1的所有数据,那么对应的SQL语句如下: '

Date:2019-11-15 读前思考: 你没想到解决办法? PostgreSQL 数据库本身就支持还是另有解决办法? 说明:首先这次数据库使用到Json数据类型的原因,这次因为我们在做了一个app 推送的业务,推送的时候,后端给app 推送 好几个字段的内容. 我们这里就直接使用了jsonb数据类型. 如下: "rule":{ "tags": { "target": "logon" }, "time":

搞定了 另外区间查询还可以支持更多的条件,只要是针对一个字段的条件都可以写到一起,例如:$map['name'] = array(array('like','%a%'), array('like','%b%'), array('like','%c%'), 'ThinkPHP','or'); 最后的查询条件是:(`name` LIKE '%a%') OR (`name` LIKE '%b%') OR (`name` LIKE '%c%') OR (`name` = 'ThinkPHP')

首先说一下,这里解决的问题应用场景: sparksql处理Hive表数据时,判断加载的是否是分区表,以及分区表的字段有哪些?再进一步限制查询分区表必须指定分区? 这里涉及到两种情况:select SQL查询和加载Hive表路径的方式.这里仅就"加载Hive表路径的方式"解析分区表字段,在处理时出现的一些问题及解决作出详细说明. 如果大家有类似的需求,笔者建议通过解析Spark SQL logical plan和下面说的这种方式解决方案结合,封装成一个通用的工具. 问题现象 sparks

PS:概要.背景.结语都是日常“装X”,可以跳过直接看优化历程 环境:SQL Server 2008 R2.阿里云RDS:辅助工具:SQL 审计 概要 一个订单列表分页查询功能,单从SQL性能来讲,从几十万数据量时,适当加一些索引随便写SQL:到百来万数据量时,需要做一些SQL语句优化:再到几百万上千万的数据量情况下,很多意想不到的情况就出现了(在大部分中小公司没有专业DBA的情况下,“万能”的研发就得顶上去了). 背景 进入公司后,系统已经初具规模,已有成型的框架.随着业务的不断增长,系统功能

简单研究了一下BLOB/TEXT字段对数据库性能的影响,得到一个大概的结论:(未验证) 无论MySQL还是MSSQL,都可以通过把BLOB/TEXT数据存储在行外的方式提高性能 把BLOB/TEXT字段单独建表保存其实意义不大,增加复杂度,而且性能比行外存储的方式提升微乎其微 行外存储的这种设计方式,在查询的时候不获取BLOB/TEXT字段,可以获得高性能 一些参考资料: https://dzone.com/articles/blob-storage-innodb https://stackov

背景: 由于本人使用的是6.0以上的版本es,在使用发现很多中文博客对于mapping参数的说明已过时.ES6.0以后有很多参数变化. 现我根据官网总结mapping最新的参数,希望能对大家有用处. es6.0与之前版本区别: -新增字段: eager_global_ordinals -删除的字段: include_in_all ※特别提示: 1,建议大家创建索引的时候指定mapping(用到特定分词器,规划字段是否被索引来节省空间等) 2,mapping创建并插入数据后就无法进行更改了!所以要

cassandra的索引查询和排序 转自:http://zhaoyanblog.com/archives/499.html   cassandra的索引查询和排序 cassandra的查询虽然很弱,但是它也是支持索引和排序的,当然是简陋的查询,这一切都是为了追求性能的代价,所以要使用cassandra,你不能希望它完全适用你的逻辑,而是把你的逻辑设计的更适合cassandra. 第一:索引查询cassandra是支持创建二级索引的,索引可以创建在除了第一个主键之外所有的列上,当然有些类型除外,例

经常有人问到oracle中的Where子句的条件书写顺序是否对SQL性能有影响,我的直觉是没有影响,因为如果这个顺序有影响,Oracle应该早就能够做到自动优化,但一直没有关于这方面的确凿证据.在网上查到的文章,一般认为在RBO优化器模式下无影响(10G开始,缺省为RBO优化器模式),而在CBO优化器模式下有影响,主要有两种观点: a.能使结果最少的条件放在最右边,SQL执行是按从右到左进行结果集的筛选的: b.有人试验表明,能使结果最少的条件放在最左边,SQL性能更高. 查过oracle8到1

之前写过一篇博客"SQL SERVER中关于OR会导致索引扫描或全表扫描的浅析",里面介绍了OR可能会引起全表扫描或索引扫描的各种案例,以及如何优化查询条件中含有OR的SQL语句的几种方法,其实还有一些方法可以用来优化这种问题,这里简单介绍一下. 如下所示,下面的SQL语句之所有出现这种写法,是因为程序的查询界面,可能有多个输入性的查询条件,往往用户只填了一个或部分查询条件(业务情况,应该不用详细介绍,大家都能明白),但是程序里面没有通过判断查询条件生成不同的SQL语句,而是用一个SQ

原文:SQL Server优化技巧--如何避免查询条件OR引起的性能问题 之前写过一篇博客"SQL SERVER中关于OR会导致索引扫描或全表扫描的浅析",里面介绍了OR可能会引起全表扫描或索引扫描的各种案例,以及如何优化查询条件中含有OR的SQL语句的几种方法,其实还有一些方法可以用来优化这种问题,这里简单介绍一下. 如下所示,下面的SQL语句之所有出现这种写法,是因为程序的查询界面,可能有多个输入性的查询条件,往往用户只填了一个或部分查询条件(业务情况,应该不用详细介绍,大家都能明

.Oracle数据库Where条件执行顺序: 由于SQL优化起来比较复杂,并且还会受环境限制,在开发过程中,写SQL必须必须要遵循以下几点的原则: 1.ORACLE采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之前, 那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾. 例如: (低效) SELECT … FROM EMP E WHERE SAL > 50000 AND JOB = ‘MANAGER’ AND 25 < (SELECT CO

有字段,a,b: a存的是:2016-10-10 b存的是:10:15:30 mysql将字段合并: concat(a, ' - ', b)  或者 concat(a, ' ', b) 字符时间转时间戳 unix_timestamp( concat(a, ' ', b) ) 别名字段作为where条件: 在MySQL中有个特殊的规定,即不允许使用列别名作为查询条件.比如有下面一个表: select     ID,     title,     concept,     conceptLength

看到有资料说,where条件的顺序会影响查询的效率,根据的逻辑是: where条件的运行是从右到左的,将选择性强的条件放到最右边,可以先过滤掉大部分的数据(而选择性不强的条件过滤后的结果集仍然很大),在根据其它条件过滤时,需要比较的数据量就少,提高查询的效率. 当我看到这个逻辑时,自我认为不是太合理,数据库引擎在执行SQL语句时,都是要经过查询优化器的,查询优化器会将SQL进行优化,选择最优的查询计划来执行,查询优化器应该会选择最优的查询计划,如果仅仅是因为where字句的顺序不同,就不能选择最

情况描述:在MySQL的user表中,对a,b,c三个字段建立联合索引,那么查询时使用其中的2个作为查询条件,是否还会走索引? 根据查询字段的位置不同来决定,如查询a,     a,b    a,b,c    a,c   都可以走索引的,其他条件的查询不能走索引. 组合索引 有“最左前缀”原则.就是只从最左面的开始组合,并不是所有只要含有这三列存在的字段的查询都会用到该组合索引. 验证过程如下所示: 首先,在SQLyog中建立一个user表,如下图所示: 对中间3个字段(user_name,us

看到有资料说,where条件的顺序会影响查询的效率,根据的逻辑是: where条件的运行是从右到左的,将选择性强的条件放到最右边,可以先过滤掉大部分的数据(而选择性不强的条件过滤后的结果集仍然很大),在根据其它条件过滤时,需要比较的数据量就少,提高查询的效率. 当我看到这个逻辑时,自我认为不是太合理,数据库引擎在执行SQL语句时,都是要经过查询优化器的,查询优化器会将SQL进行优化,选择最优的查询计划来执行,查询优化器应该会选择最优的查询计划,如果仅仅是因为where字句的顺序不同,就不能选择最

Question表与Paper表 Paper表中字段QuestionIds存储的是Question表中字段Id的拼接后的值 如: 'f855eba1-b308-4bd7-a250-c071a0e1bdf0','c0570880-931b-4b34-ba34-58937f940c21','96249256-ddd7-4b28-a066-ebe1c337cf6c','c0b6171a-1b50-4881-a5f5-9928ce1bf593','b71ad813-abad-40f2-bf97-a1ae

Criteria 查询条件如果是子对象中的非主键字段会报 could not resolve property private Criteria getCriteria(Favorite favorite) { Criteria criteria = importDaoService.favoriteDao.getCriteria(); if (favorite.getStatus() != null) { criteria.add(Restrictions.eq("status",

/* * 查询提取位置表所有数据 * */ public String ListEtlExtractPositionOfAll(){ // 接受数据库中传送的code int code = Integer.parseInt(get("code").toString().trim()); this.getmenu(code, this.getRequest()); StringBuffer where = new StringBuffer("1=1"); String

1.Text字段排序 场景:数据库中按照某个字段排序,sql只需写order by 字段名即可,如果es对一个text field进行排序,es中无法排序.因为文档入倒排索引表时,分词存入,es无法知道此字段的真实值.这样的结果往往不准确,因为分词后是多个单词,再排序就不是我们想要的结果了. 通常有两种解决办法: 将一个text field建立两次索引,一个分词,用来进行搜索:一个不分词,用来进行排序. mapping时设置fielddata:true,按照第一个分词进行字典序排序.这种方式也不