一般情况下，使用ORM框架来完成单个实体的查询是很方便的，但如果有复杂的查询条件，普通的ORM组件比较困难，PDF.NET数据开发框架的ORM实体类查询语言--OQL，使得构造复杂的查询条件成为可能，参加我的其它相关文章。 很多ORM框架都只能处理单个实体的查询，但如果要连表查询就比较困难了，主要问题是连表查询的结果无法投射到一个实体类中，这时候只有动态创建一个类来处理，比如LINQ的Select功能。在PDF.NET数据开发框架中，多表连接查询推荐使用SQL-MAP功能（参加我的相关文章）
JPA 这部分内容上手很容易，但是涉及到的东西还是挺多的，网上大部分关于 JPA 的资料都不是特别齐全，大部分用的版本也是比较落后的。另外，我下面讲到了的内容也不可能涵盖所有 JPA 相关内容，我只是把自己觉得比较重要的知识点总结在了下面。很多地方我自己也是参考着官方文档写的，官方文档非常详细了，非常推荐阅读一下。这篇文章可以帮助对 JPA 不了解或者不太熟悉的人来在实际项目中正确使用 JPA。
当感觉mysql性能出现问题时，通常会先看下当前mysql的执行状态，使用 show processlist 来查看，例如 mysql> show processlist; +—–+————-+——————–+ | Id | User | Host | db | Command | Time| State | Info +—–+————-+——————–+ |207|root |192.168.0.2:51621 |mytest | Sleep | 5 | | NULL |208|root |192.168
概述： 交代一下背景，这算是一次项目经验吧，属于公司一个已上线平台的功能，这算是离职人员挖下的坑，随着数据越来越多，原本的SQL查询变得越来越慢，用户体验特别差，因此SQL优化任务交到了我手上。 这个SQL查询关联两个数据表，一个是攻击IP用户表主要是记录IP的信息，如第一次攻击时间，地址，IP等等，一个是IP攻击次数表主要是记录每天IP攻击次数。而需求是获取某天攻击IP信息和次数。（以下SQL语句测试均在测试服务器上上，正式服务器的性能好，查询时间快不少。）
SQL优化中，有一条放之四海而皆准的既定方针，那就是：永远以小数据驱动大数据。其本质其实就是以小的数据样本作为驱动查询能够优化查询效率，在SQL中，涉及到不同表数据的连接、转移、或者合并，这些操作必须得有个数据集作为“带头”大哥，即驱动数据，而这个驱动数据最好是数据量最小的那一个。
本人在做测试服务的过程中，开发了一个功能，就是从两个库的两张表从查出来一个账号的login_id和user_id，功能非常简单，就是执行sql语句，处理返回结果，再返回。
某天本猿按部就班地上班，喝着一杯刚刚好的白开水，一缕阳光透过没有关好的窗帘偷偷照进了我的座位，看着安静的工作群，刷着各种新闻，溜达一下各大社区，这摸鱼时间真的太好了。。。然鹅，客服小姐姐的一条消息打破一切的宁静，又要开始修BUG了!!!!
本文使用到的是oracle数据库scott方案所带的表,scott是oracle数据库自带的方案,使用前请确保其解锁 一、多行子查询 多行子查询子查询是嵌入在其他Sql语句中的select语句,Ora
注：本文为技术讨论会上的内容要点摘录整理的，相关内容仅作参考。 1 “模型”的几个概念 下面这2个名词容易混淆： Module---模块，通常按照功能来划分，比如按照业务功能来划分 Model --模型，它通常出现在下面几个概念中： l MVVM --Model+View+ViewModel l MVP --Model+View+Presenter l MVC --Model+View+Controller 所以常说的Model实际上包含了View Model，Domain Model
在多表查询时，on 比 where 更早起作用。系统首先根据各个表之间的联接条件，把多个表合成一个临时表后，再由 where 进行过滤，然后再计算，计算完后再由 having 进行过滤。由此可见，要想过滤条件起到正确的作用，首先要明白这个条件应该在什么时候起作用，然后再决定放在那里。
在日常开发中，数据库的增删改查（CDUR）中，查询需求偏多，所以查询的语法比增删改操作多得多，尤其是跨表关联查询，可以让代码精简很多。
强调互联网，这是因为本文所讨论的前提是互联网应用。与“传统”应用不同，互联网中的应用每天面临的是海量的数据、大量的请求以及对系统可靠性和响应速度有着更高的要求。“传统”应用，我姑且浅显地认为是，数据量不大，面对的用户群范围相对较小，自然大量的高并发请求场景几乎不存在。
SQLAlchemy是Python编程语言下的一款ORM框架，该框架建立在数据库API之上，使用关系对象映射进行数据库操作，简言之便是：将对象转换成SQL，然后使用数据API执行SQL并获取执行结果。
什么是查询构造器？其实就像我们上篇文章中学习过的使用原始 SQL 语句的方式来操作数据库一样，查询构造器这个东西就是在这个原始操作的基础上为我们封装了一系列的接口，能够让我们方便地来操作数据库。或者说，就是像我们很早前自己封装的那种 MySQL 类一样，框架帮我们完成了这一步。并且，最主要的是，它可以让我们以链式调用的形式来操作数据库，从而避免去写繁杂混乱的 SQL 语句。先卖个关子，想想这和哪个设计模式有关？（文中自会揭晓）
建表的角度上 1、合理安排表关系 2、尽量把固定长度的字段放在前面 3、尽量使用char 代替varchar 4、分表：水平分和垂直分
MySQL程序可以使用PHP study集成工具。链接、操作数据库可以使用phpstudy自带的工具也可以使用navicat工具。
摘要: 高并发一直是然个人头疼的问题；然而，其解决方式则是一套组合策略，由整体入手，逐步分析，逐步解决部分问题，进而解决所有问题；就像一支庞大的输水管道，不断的做分支导流，每层的分支可以导出部分的流量，继而顺利导出所有的流量。 总体思路：优化代码，分离业务逻辑，数据库,最后加服务器等； 逐步解决方案，具体操作如下： (1).页面的动静分离： 页面生成了静态的缓存，页面中的图片、JS等静态资源推CDN; 动态数据，能做缓存的做缓存（redis,memache）;不能做缓存的，开始从代码层面下着手； (2).
数据库就是一个以某种有组织的方式存储的数据集合。 简单的说，数据库（database）就是一个存放数据的仓库，这个仓库是按照一定的数据结构（数据结构是指数据的组织形式或数据之间的联系）来组织、存储的，我们可以通过数据提供的多种方法来管理数据库里的数据。
在当今这个互联网的时代无非要解决两大难题，其一是信息安全，其二就是数据的存储。而信息安全则是在数据存储的基础之上。一个公司从刚开始成立到发展成一个有上百人甚至上千人团队的时候，公司的业务量是呈上升趋势，客户及用户也会越来越多；之前设计的表结构可能会显得不合理，表与表之间的联系没有一个稳定的业务功能划分，从而表现出来的是相关表的备用字段越来越不够用甚至新加字段，最坏的情况就是不同业务表之间会有数据冗杂。从而暴露出一些设计的问题，这也就是SQL优化点之一：数据库表结构设计的合理性。近年来大数据越来越火，而大数据也是为了解决数据的存储的手段之一，其目的是从海量的数据中收集到有价值的信息然后存储到数据库中，因为数据量大传统的数据库无法储存那么多的信息所以需要分析有价值的信息后再做决定是否持久化。
阿粉相信，现在很多的做开发的都喜欢研究一些新的技术，但是能不能把数据都实际应用到公司的环境中，这个就不好说了，毕竟有些东西用上了，一旦出现问题了，那么就会导致一连串的生产事故的发生。今天阿粉就来学习一下这个Sharding，也就是分库分表实战，接下来我们来学习一下什么是分库分表，什么是Sharding。
通过执行计划可以看出,先执行的是DEPENDENT SUBQUERY这部分(id大的优先执行),也就是select dname from dept d where e.deptno = d.deptno但是这部分是不能单独执行的,所以猜测mysql对这部分做了处理,处理成类似这种select d.dname,e.deptno from dept d join emp e on d.deptno = e,deptno,生成了一个临时表,然后再执行主表和临时表的连表查询(临时表的意思是啥?比如dept表有很多列,同时又很多行,其中还有一大部分不满足d.deptno = e,deptno这个条件,此时临时表相对于对大表做了一个精简)
SQL，指结构化查询语言，全称是 Structured Query Language，是一种 ANSI（American National Standards Institute 美国国家标准化组织）标准的计算机语言，可以让我们可以处理数据库。
趁着下午的空闲时间，研究了一下mybatis-flex，看着对我还是挺有吸引力的。于是打开了官网，先从代码生成开始：
说到数据库每次面试都会在sql语句上吃大亏，考察的问题无非是去重，连表查询，求最值，平均值等，看起来很简单吧，但是写起来还真有点困难，不会sql面试会大打折扣。于是决定好好整理下sql，希望对大家有帮助
sql执行结果 确实是四条。 到此真相大白，确实是插件的锅。查看插件源码：
本文实例讲述了laravel5.6框架操作数据curd写法(查询构建器)。分享给大家供大家参考，具体如下：
在看此篇前，建议先阅读MySQL索引，对索引有个基本了解：MySQL数据库进阶-索引-CSDN博客
为了让这个库更好用，我比较研究了各语言的主流ORM库，发现有一些语言的ORM库确实很好用，而有另外一些语言的库那不是一般的难用。
写SQL语句不难，稍微系统学习过数据库相关技术的人都能做到，但想要写好SQL却也不是一件易事，在大多数编写SQL的时候，很多人都是以实现需求为原则去撰写的，当一条SQL写出来之后，只要能满足业务需求就行，不会考虑它有没有优化点，能不能让它跑的更快。
在正式开始之前，菜菜还是要强调一点，你的数据表是否应该分，需要综合考虑很多因素，比如业务的数据量是否到达了必须要切分的数量级，是否可以有其他方案来解决当前问题？我不止一次的见过，有的leader在不考虑综合情况下，盲目的进行表拆分业务，导致的情况就是大家不停的加班，连续几周996，难道leader你不掉头发吗？还有的架构师在一个小小业务初期就进行表拆分，大家为了配合你也是马不停蹄的加班赶进度，上线之后反而发现业务数据量很小，但是代码上却被分表策略牵制了太多。拆表引起的问题在特定的场景下，有时候代价真的很大。
转载请注明源地址：http://www.cnblogs.com/funnyzpc/p/8495453.html
这周公司开发工作比较悠闲，工作几乎压在设计上游，于是整理了下公司开发的文档，包括项目架构、服务器运维、规范、api对接、基本依赖信息等。如下是包含其中的MySQL开发规范，根据社区很多的博文参考以及结合自身小团队开发情况总结。
数据库主要是用来存储的，我们应避免让数据库做运算，比如写定时任务，存储过程等。复杂的计算应该在程序代码中实现。我们应该尽量简单的使用数据库。
SpringBoot中关于Mybatis使用的三个问题 转载请注明源地址：http://www.cnblogs.com/funnyzpc/p/8495453.html 原本是要讲讲PostgreSQL的一些学习总结的，不巧的是最近一段时间的进度都是一些类似于加减乘除、位移、类型转换的稍显小儿科的一些内容，额~(ಠ .̫.̫ ಠ)，这也不是什么问题，只是觉得这中间没什么终点和难点可讲的，也就暂时略过了~，这里首先说声抱歉啊，后续如有什么使用难点或有趣的地方一定拿出来讲讲♥◠‿◠)ﾉ；额，每次开篇总要讲一
两张表连表查询可以使用join、exists和in等方式，其中exists和in都属于依赖子查询。参考博客1给出了三种方式使用场景。本文记录一次将join查询转换成exists查询后，性能得到了20倍以上的提升。
字符集：是一个系统支持的所有抽象字符的集合。字符是各种文字和符号的总称，包括各国家文字、标点符号、图形符号、数字等。
所有java面经系列已同步到我的github，欢迎访问https://github.com/tzfun/Java-Interview-experience，记得给颗星星支持一下哦~~
最近看到一篇博客《撸一段 SQL ? 还是撸一段代码？》，文章举例说明了一个连表查询使用程序code来写可读性可维护性更好，但是回帖意见不一致，我想作者在理论层面没有做出更好的论述，而我今天才
在数据爆发式增长的时代，记录数据变化和演变，探究内在规律并运用到生产实践中，驱动业务的增长成为这个时代主旋律。本文就如何记录数据变化，处理数据变化谈谈自己的理解
注意:本文基于mysql5.7进行操作,各个版本的mysql使用Explan会有微小的差异
数据库专题（一） ——数据库优化 （原创内容，转载请注明来源，谢谢） 一、概述 数据库的优化通常分为三个方面：数据库DML、DQL的优化（即增删改查等SQL语句优化）；数据库设计优化（如索引设置、索引类型、表引擎、冗余字段、主键外键等）；数据库服务器和配置优化（如主从分离、读写分离等）。 根据不同的业务场景，需要进行不同的优化措施。 二、数据库语句优化 程序对数据库的操作，绝大部分来自查询，因此查询的优化至关重要，而大部分情况下，查询的优化在于索引命中率。网络上有很多查询优化的例子，在此主要说几点。
《「一起学」》系别终于启动了，这个系列我主要会「按照我学习的思路」，给大家更新一下，为的是「学习方法和思路」，当然重要的还有知识，以及 moon 平常是怎么学习一个新的技术的
转载请注明出处：帘卷西风的专栏(http://blog.csdn.net/ljxfblog)
这里第一句话很关键，文档上说，mongoDB 是一个「文档型数据库，旨在简化开发和扩展」。
前面文章，我们学习了 MySQL 慢日志相关内容，当我们筛选得到具体的慢 SQL 后，就要想办法去优化啦。优化 SQL 的第一步应该是读懂 SQL 的执行计划。本篇文章，我们一起来学习下 MySQL explain 执行计划相关知识。
服务端API的设计与开发，为客户端提供产品业务所需要的各种功能和数据接口。随着APP产品的迭代更新，APP Server提供的接口往往也会进行多个版本的迭代更新。如何优雅的维护接口的稳定性，设计扩展性满足将来一定的业务需求变更，一直是从事服务端接口开发工程师需要不断思考的问题。
Column ‘create_time’ in order clause is ambiguous
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
云直播
