数据库系统

腾讯面试:一条SQL语句执行得很慢的原因有哪些?---不看后悔系列

岁酱吖の 提交于 2019-12-21 05:27:19
说实话,这个问题可以涉及到 MySQL 的很多核心知识,可以扯出一大堆,就像要考你计算机网络的知识时,问你“输入URL回车之后,究竟发生了什么”一样,看看你能说出多少了。 之前腾讯面试的实话,也问到这个问题了,不过答的很不好,之前没去想过相关原因,导致一时之间扯不出来。所以今天,我带大家来详细扯一下有哪些原因,相信你看完之后一定会有所收获,不然你打我。 开始装逼:分类讨论 一条 SQL 语句执行的很慢,那是每次执行都很慢呢?还是大多数情况下是正常的,偶尔出现很慢呢?所以我觉得,我们还得分以下两种情况来讨论。 1、大多数情况是正常的,只是偶尔会出现很慢的情况。 2、在数据量不变的情况下,这条SQL语句一直以来都执行的很慢。 针对这两种情况,我们来分析下可能是哪些原因导致的。 针对偶尔很慢的情况 一条 SQL 大多数情况正常,偶尔才能出现很慢的情况,针对这种情况,我觉得这条SQL语句的书写本身是没什么问题的,而是其他原因导致的,那会是什么原因呢? 数据库在刷新脏页我也无奈啊 当我们要往数据库插入一条数据、或者要更新一条数据的时候,我们知道数据库会在 内存 中把对应字段的数据更新了,但是更新之后,这些更新的字段并不会马上同步持久化到 磁盘 中去,而是把这些更新的记录写入到 redo log 日记中去,等到空闲的时候,在通过 redo log 里的日记把最新的数据同步到 磁盘 中去。 不过

Python常用的标准库以及第三方库

此生再无相见时 提交于 2019-12-21 04:24:32
参考: https://www.cnblogs.com/jiangchunsheng/p/9275881.html 20个必不可少的Python库也是基本的第三方库 读者您好。今天我将介绍20个属于我常用工具的Python库,我相信你看完之后也会觉得离不开它们。他们是: Requests.Kenneth Reitz写的最富盛名的http库。每个Python程序员都应该有它。 Scrapy.如果你从事爬虫相关的工作,那么这个库也是必不可少的。用过它之后你就不会再想用别的同类库了。 wxPython.Python的一个GUI(图形用户界面)工具。我主要用它替代tkinter。你一定会爱上它的。 Pillow.它是PIL(Python图形库)的一个友好分支。对于用户比PIL更加友好,对于任何在图形领域工作的人是必备的库。 SQLAlchemy.一个数据库的库。对它的评价褒贬参半。是否使用的决定权在你手里。 BeautifulSoup.我知道它很慢,但这个xml和html的解析库对于新手非常有用。 Twisted.对于网络应用开发者最重要的工具。它有非常优美的api,被很多Python开发大牛使用。 NumPy.我们怎么能缺少这么重要的库?它为Python提供了很多高级的数学方法。 SciPy.既然我们提了NumPy,那就不得不提一下SciPy。这是一个Python的算法和数学工具库

SQL Server DBCC命令大全

你离开我真会死。 提交于 2019-12-20 07:31:15
SQL Server DBCC命令大全 原文出处: https://www.cnblogs.com/lyhabc/archive/2013/01/19/2867174.html DBCC DROPCLEANBUFFERS:从缓冲池中删除所有缓存,清除缓冲区 在进行测试时,使用这个命令可以从SQLSERVER的数据缓存data cache(buffer)清除所有的测试数据,以保证测试的公正性。 需要注意的是这个命令只移走干净的缓存,不移走脏缓存。由于这个原因,在执行这个命令前,应该先执行CheckPoint,将所有脏的缓存写入磁盘, 这样在运行DBCC RROPCLEANBUFFERS 时,可以保证所有的数据缓存被清理,而不是其中的一部分。 DBCC CacheStats:显示存在于当前buffer Cache中的对象的信息,例如:hit rates,编译的对象和执行计划 DBCC ErrorLog :如果很少重启mssqlserver服务,那么服务器的日志(不是数据库事务日志)会增长得很快,而且打开和查看日志的速度也会很慢 使用这个命令,可以截断当前的服务器日志,主要是生成一个新的日志。可以考虑设置一个调度任务,每周执行这个命令自动截断服务器日志。 使用存储过程sp_cycle_errorlog也可以达到同样的目的 一、DBCC 帮助类命令 DBCC HELP('?')

面试之数据库分表

♀尐吖头ヾ 提交于 2019-12-20 04:55:38
数据库分表) 数据切分 垂直(纵向)切分 水平(横向)切分 分库分表带来的问题 1. 事务一致性问题 2. 跨节点关联查询 join 问题 3. 跨节点分页、排序、函数问题 4. 全局主键避重问题 1. UUID 2. 结合数据库维护主键ID表 3. Snowflake分布式自增ID算法 5. 数据迁移、扩容问题 什么时候考虑切分 1. 能不切分尽量不要切分 2. 数据量过大,正常运维影响业务访问 3. 随着业务发展,需要对某些字段垂直拆分 4. 数据量快速增长 5. 安全性和可用性 案例分析 1. 用户中心业务场景 2. 水平切分方法 "根据数值范围":以主键uid为划分依据,按uid的范围将数据水平切分到多个数据库上。 "根据数值取模":也是以主键uid为划分依据,按uid取模的值将数据水平切分到多个数据库上。 3. 非uid的查询方法 1. 建立非uid属性到uid的映射关系 1. 映射关系 2. 基因法 2. 前台与后台分离 支持分库分表中间件 数据切分 关系型数据库本身比较容易成为系统瓶颈,单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后,由于查询维度较多,即使添加从库、优化索引,做很多操作时性能仍下降严重。此时就要考虑对其进行切分了,切分的目的就在于减少数据库的负担,缩短查询时间。 数据库分布式核心内容无非就是数据切分(Sharding)

开发之缓存与数据库优化

核能气质少年 提交于 2019-12-20 02:09:10
此文仅入门,需要扩展挖深,自行钻研 缓存-redis 数据库-mysql 1. 缓存 什么是缓存? 定义 缓存是系统快速响应的一种关键性技术,是一组被保存起来以备将来使用的东西,介于应用开发和系统开发之间,是产品经理们经常顾及不到的地方,也是技术架构设计的非功能性约束。 分类 按软件系统所处的位置不同分类 客户端缓存 服务端缓存 网络中的缓存 按规模和部署方式分类: 单体缓存 缓存集群 分布式缓存 为什么要用缓存? 为什么要用缓存,我们这里仅从软件开发层面来分析,首先你必须了解关于系统的性能的一些指标。 系统的性能的指标一般包括: 响应时间:系统对用户的请求作出的响应时间,它完整的记录了整个系统处理请求的时间。 延迟时间:一般指系统处理完请求后,由于网络传输到用户之间的网络延迟时间。 吞吐量:指单位时间内系统处理请求的数量。无并发的系统中,它与响应时间成反比。 并发用户数:指系统能够同时承载的正常使用系统功能的用户数量,它比 吞吐量更能直观的反应系统的性能 资源利用率:反映的是一段时间内资源平均被占用的情况 系统的性能,反映在从浏览器到网络,再到服务器,甚至数据库等各个应用层面。而在各个层面使用缓存将大大提升整个系统的性能。 缓存离客户端越近,响应时间则越快;缓存离数据库越近,则响应时间越长。 缓存是一种用空间换时间的概念。 如果带宽收费(流量付费),那么缓存就是变相的省钱利器。

数据库连接池的问题

谁都会走 提交于 2019-12-19 12:50:14
数据库连接池技术带来的优势: 1. 资源重用 由于数据库连接得到重用,避免了频繁创建、释放连接引起的大量性能开销。在减少系统消耗的基础上,另一方面也增进了系统运行环境的平稳性(减少内存碎片以及数据库临时进程/线程的数量)。 2. 更快的系统响应速度 数据库连接池在初始化过程中,往往已经创建了若干数据库连接置于池中备用。此时连接的初始化工作均已完成。对于业务请求处理而言,直接利用现有可用连接,避免了数据库连接初始化和释放过程的时间开销,从而缩减了系统整体响应时间。 3. 新的资源分配手段 对于多应用共享同一数据库的系统而言,可在应用层通过数据库连接的配置,实现数据库连接池技术,几年钱也许还是个新鲜话题,对于目前的业务系统而言,如果设计中还没有考虑到连接池的应用,那么…….快在设计文档中加上这部分的内容吧。某一应用最大可用数据库连接数的限制,避免某一应用独占所有数据库资源。 4. 统一的连接管理,避免数据库连接泄漏 在较为完备的数据库连接池实现中,可根据预先的连接占用超时设定,强制收回被占用连接。从而避免了常规数据库连接操作中可能出现的资源泄漏。一个最小化的数据库连接池实现. 连接池类是对某一数据库所有连接的“缓冲池”,主要实现以下功能:①从连接池获取或创建可用连接;②使用完毕之后,把连接返还给连接池;③在系统关闭前,断开所有连接并释放连接占用的系统资源;④还能够处理无效连接

数据库构思与设计规范

怎甘沉沦 提交于 2019-12-19 05:41:24
一、 数据库模型构思(数据库设计步骤) a) 数据库模型理解 数据库模型设计是编写软件就像建筑结构对于工程师们。工程师们学习所有的设计艺术比如浴室应该放哪和有多少个浴室,以及是否有浴室。如果这些结构设计留给土木工程师,他们也许会忘记这些浴室或者把问题遗留给居住的人们。这就非常类似数据库结构和与开发人员之间设计问题。 土木工程师们确保我们的建筑上的砖头不会砸到我们,而建筑师们让建筑 更加的适合居住。是什么导致我们在软件,数据库建模中不得不设计数据库模 型。本质上来说,设计过程中涉及具体的对象构建前把我们的思路写在纸上, 或者可能移动一些零件和部件以获取他们期待的设计。而一般的土木工程师 (开发人员)可能不会关注设计数百万吨的混凝土的预制结构。就类似数据库 模型的建立,你需要在构建之前和开始填充数据以及连接到应用程序之前建立 他的数据库模型。 数据库的设计是如此的重要因为所有应用程序都是针对数据库模型设计的,他们完全依赖于底层数据的结构。如果数据库模型在后一阶段有所改变,所有以数据库模型为基础的任何东西都有可能需要改变甚至全部重写。他们就需要非常大的财力和精力花费。设计数据库模型我们通常需要使用一些工具,流程图,图片,以及实体关系图(ERD)和任何能帮助我们确定设计思路的东西。 b) 确定(实现)的目标 确定目标可能是一个最重要的任务做任何项目的规划

201621123012 《Java程序设计》第14次学习总结

♀尐吖头ヾ 提交于 2019-12-19 02:22:22
作业14-数据库 1. 本周学习总结 1.1 以你喜欢的方式(思维导图或其他)归纳总结与数据库相关内容。 2. 使用数据库技术改造你的系统 2.1 简述如何使用数据库技术改造你的系统。要建立什么表?截图你的表设计。 答:我建立了一个图书馆数据库,为这个库分别创建了3个表。图书信息表,用户表,用户借书还书信息表。 。 2.2 系统中使用到了JDBC中什么关键类? java.sql.Connection java.sql.DriverManager java.sql.ResultSet java.sql.Statement java.sql.SQLException 2.3 截图数据库相关模块的关键代码。关键行需要加注释。 答:利用语句对数据库做修改,然后重构链表来实施功能实现。 2.4 选做:使用JDBCUtil进行改造系统。 答: 3. 代码量统计 3.1 统计本周完成的代码量 周次 总代码量 新增代码量 总文件数 新增文件数 1 113 113 13 13 2 365 252 23 10 3 666 301 28 5 4 883 217 36 8 5 1095 212 40 4 6 1750 655 51 11 7 3412 1662 60 9 8 3653 241 65 5 9 4062 409 70 5 10 4351 289 79 9 11 4747 396 88 9 12

informix 数据库锁表分析和解决方法

人盡茶涼 提交于 2019-12-19 01:57:00
在联机事务处理(OLTP)的数据库应用系统中,多用户、多任务的并发性是系统最重要的技术指标之一。为了提高并发性,目前大部分RDBMS都采用加锁技术。然而由于现实环境的复杂性,使用加锁技术又不可避免地产生了死锁问题。因此如何合理有效地使用加锁技术,最小化死锁是开发联机事务处理系统的关键。 死锁产生的原因 在联机事务处理系统中,造成死机主要有两方面原因。一方面,由于多用户、多任务的并发性和事务的完整性要求,当多个事务处理对多个资源同时访问时,若双方已锁定一部分资源但也都需要对方已锁定的资源时,无法在有限的时间内完全获得所需的资源,就会处于无限的等待状态,从而造成其对资源需求的死锁。 另一方面,数据库本身加锁机制的实现方法不同,各数据库系统也会产生其特殊的死锁情况。如在Sybase SQL Server 11中,最小锁为2K一页的加锁方法,而非行级锁。如果某张表的记录数少且记录的长度较短(即记录密度高,如应用系统中的系统配置表或系统参数表就属于此类表),被访问的频率高,就容易在该页上产生死锁。 容易发生死锁的几种情况如下: 1>不同的存储过程、触发器、动态SQL语句段按照不同的顺序同时访问多张表; 2>在交换期间添加记录频繁的表,但在该表上使用了非群集索引(non-clustered); 3>表中的记录少,且单条记录较短,被访问的频率较高; 4>整张表被访问的频率高(如代码对照表的查询等

分库分表的几种常见玩法及如何解决跨库查询等问题

荒凉一梦 提交于 2019-12-18 20:14:19
摘要:在谈论数据库架构和数据库优化的时候,我们经常会听到“分库分表”、“分片”、“Sharding”…这样的关键词。让人感到高兴的是,这些朋友所服务的公司业务量正在(或者即将面临)高速增长,技术方面也面临着一些挑战。让人感到担忧的是,他们系统真的就需要“分库分表”了吗?“分库分表”有那么容易实践吗?为此,笔者整理了分库分表中可能遇到的一些问题,并结合以往经验介绍了对应的解决思路和建议。垂直分表垂直分表在日常开发和设计中比较常见,通俗的说法叫做“大表拆小表”,拆分是基于关系型数据库中 在谈论数据库架构和数据库优化的时候,我们经常会听到“分库分表”、“分片”、“Sharding”…这样的关键词。让人感到高兴的是,这些朋友所服务的公司业务量正在(或者即将面临)高速增长,技术方面也面临着一些挑战。让人感到担忧的是,他们系统真的就需要“分库分表”了吗?“分库分表”有那么容易实践吗?为此,笔者整理了分库分表中可能遇到的一些问题,并结合以往经验介绍了对应的解决思路和建议。 垂直分表 垂直分表在日常开发和设计中比较常见,通俗的说法叫做“大表拆小表”,拆分是基于关系型数据库中的“列”(字段)进行的。通常情况,某个表中的字段比较多,可以新建立一张“扩展表”,将不经常使用或者长度较大的字段拆分出去放到“扩展表”中,如下图所示: 小结 在字段很多的情况下,拆分开确实更便于开发和维护