• 关于

    key设计原则

    的搜索结果

回答

本文介绍了使用云服务器ECS标签的最佳实践。您可以通过标签管理、分类和检索数字资产。 应用场景 随着您云上资源的增加,管理难度也随之变化,您可以通过标签实现批量管理资源。标签是人员、财务、物品管理的重要分组工具,帮助您横向连通云产品。标签的常见场景包括资源管理、访问控制和自动化运维及分账等,如下所示: 管理应用发布流程 资源溯源,基于标签分组检索和管理资源 搭配运维编排服务、资源编排、弹性伸缩和云助手等实现基于标签自动化分组运维 基于标签管理成本和分账 设计资源或角色访问控制 原则概述 您在创建标签时,可以根据以下设计原则实现标签最佳实践: 互斥原则 集体详尽原则 有限值原则 考虑未来变化后果原则 简化设计原则 互斥原则 互斥是指尽量避免对同一个属性含义使用两个或以上的标签键。例如标记归属者用key="owner"表示时,就不能使用其他相同含义的标签键,如own、belonger或归属者等。 集体详尽原则 集体详尽是指规划资源时,您需要同时规划标签,并优先规划标签键。所有资源对象都必须绑定已规划的标签键及其对应的标签键。 标签键值对需要采用标准化命名格式。 集体详尽原则是后续通过标签维度在访问控制、成本跟踪、自动化运维以及分组搜索的必要条件。 有限值原则 有限值是指为资源剔除多余的标签值,只保留核心标签值。 有限值原则简化了资源管理、访问控制、自动化运维及分账等流程。您还可以结合标签及自动化工具管理资源,云服务器ECS支持通过API编程控制标签,方便您自动管理、检索和筛选资源。 考虑未来变化后果原则 您需要在满足有限值的前提下,在规划标签时同时考虑后续工作中增加或者减少标签值的影响,提高标签修改的灵活性。 当您修改标签时,可能会引起基于标签的访问控制、自动化运维或相关账单报表的变化。无论是公司或个人层面的业务,最佳实践是创建与业务相关的标签组,以便从技术、业务和安全维度管理资源。使用自动化运维来管理其资源及服务时,还设计额外的自动化专用的标签,帮助您完成自动化运维工作。 简化设计原则 简化设计原则是指简化标签键的使用,在规划标签时使用固定维度的标签键。简化设计原则可减少由于过多的标签键导致的操作报错。 您可以创建与业务相关的标签组,方便您从技术、业务或安全等维度管理资源。 使用自动化运维工具管理资源及服务时,您可以设计自动化运维专用的标签。 标签键设计示例 下表列举了常见业务维度的标签命名示例。涉及英文标签命名时,建议使用小写英文字母。 业务维度 标签键(key) 标签值(value) 组织架构 company department organization team group 相关名称 业务架构 product business module service 相关名称 角色架构 role user 网络管理员 应用管理员 系统管理员 运维管理员或OpsUser 研发或DevUser 测试或TestUser 用途类标签 purpose use 用途值 项目类标签 项目维度: project risk schedule subtask environment 人员维度: sponsor member decisionMaker或owner creator 项目相关值 业务部门(实现成本分配和业务跟踪) costcenter businessunit biz financecontact 部门相关值 财务维度责任人(确定资源负责人) owner 人名或邮箱等 财务维度客户(识别资源组服务的客户) 自定义或真实值 客户名称 财务维度项目(确定资源支持的项目) project 项目名称 财务维度订单 order 订单分类ID

1934890530796658 2020-03-26 10:56:59 0 浏览量 回答数 0

回答

互斥原则 互斥是指尽量避免对同一个属性含义使用两个或以上的标签键。例如标记归属者用key="owner"表示时,就不能使用其他相同含义的标签键,如own、belonger或归属者等。 集体详尽原则 集体详尽是指规划资源时,您需要同时规划标签,并优先规划标签键。所有资源对象都必须绑定已规划的标签键及其对应的标签键。 标签键值对需要采用标准化命名格式。 集体详尽原则是后续通过标签维度在访问控制、成本跟踪、自动化运维以及分组搜索的必要条件。 有限值原则 有限值是指为资源剔除多余的标签值,只保留核心标签值。 有限值原则简化了资源管理、访问控制、自动化运维及分账等流程。您还可以结合标签及自动化工具管理资源,云服务器ECS支持通过API编程控制标签,方便您自动管理、检索和筛选资源。 考虑未来变化后果原则 您需要在满足有限值的前提下,在规划标签时同时考虑后续工作中增加或者减少标签值的影响,提高标签修改的灵活性。 当您修改标签时,可能会引起基于标签的访问控制、自动化运维或相关账单报表的变化。无论是公司或个人层面的业务,最佳实践是创建与业务相关的标签组,以便从技术、业务和安全维度管理资源。使用自动化运维来管理其资源及服务时,还设计额外的自动化专用的标签,帮助您完成自动化运维工作。 简化设计原则 简化设计原则是指简化标签键的使用,在规划标签时使用固定维度的标签键。简化设计原则可减少由于过多的标签键导致的操作报错。 您可以创建与业务相关的标签组,方便您从技术、业务或安全等维度管理资源。 使用自动化运维工具管理资源及服务时,您可以设计自动化运维专用的标签。 标签键设计示例 下表列举了常见业务维度的标签命名示例。涉及英文标签命名时,建议使用小写英文字母。 业务维度 标签键(key) 标签值(value) 组织架构 company department organization team group 相关名称 业务架构 product business module service 相关名称 角色架构 role user 网络管理员 应用管理员 系统管理员 运维管理员或OpsUser 研发或DevUser 测试或TestUser 用途类标签 purpose use 用途值 项目类标签 项目维度: project risk schedule subtask environment 人员维度: sponsor member decisionMaker或owner creator 项目相关值 业务部门(实现成本分配和业务跟踪) costcenter businessunit biz financecontact 部门相关值 财务维度责任人(确定资源负责人) owner 人名或邮箱等 财务维度客户(识别资源组服务的客户) 自定义或真实值 客户名称 财务维度项目(确定资源支持的项目) project 项目名称 财务维度订单 order 订单分类ID

景凌凯 2020-03-25 18:45:45 0 浏览量 回答数 0

回答

最好的分区原则: 初次接触HBase的客户,在创建HBase表的时候,不指分区的数目,另外就是rowkey设计不合理,导致热点。 最为常见的建表语句为: create ‘t3’,’f1’, { NUMREGIONS => 50, SPLITALGO => ‘HexStringSplit’ , COMPRESSION => ‘snappy’} 其中 NUMREGIONS 为 region的个数,一般取10-500左右,集群规模大,可以取大一些,SPLITALGO 为 rowkey分割的算法:Hbase自带了两种pre-split的算法,分别是 HexStringSplit 和 UniformSplit,HexStringSplit 如果我们的row key是十六进制的字符串作为前缀的,就比较适合用HexStringSplit,关于rowkey的设计可以参考:RowKey设计COMPRESSION压缩算法,参考:数据压缩与编码 文档地址:https://help.aliyun.com/document_detail/71787.html?spm=a2c4g.11186623.6.572.3a0278f0ORQunR

封神 2019-12-02 01:41:20 0 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

回答

Java集合容器主要有以下几类:1,内置容器:数组2,list容器:Vetor,Stack,ArrayList,LinkedList,CopyOnWriteArrayList(1.5),AttributeList(1.5),RoleList(1.5),RoleUnresolvedList(1.5),ConcurrentLinkedQueue(1.5),ArrayBlockingQueue(1.5),LinkedBlockingQueue(1.5),PriorityQueue(1.5),PriorityBlockingQueue(1.5),SynchronousQueue(1.5)3,set容器:HashSet(1.2),LinkedHashSet(1.4),TreeSet(1.2),CopyOnWriteArraySet(1.5),EnumSet(1.5),JobStateReasons。4,map容器:Hashtable,HashMap(1.2),TreeMap(1.2),LinkedHashMap(1.4),WeakHashMap(1.2),IdentityHashMap(1.4),ConcurrentMap(1.5),concurrentHashMap(1.5)。注意:Vector,Stack,Hashtable是Java1.2前的容器。虽然在Java2之前,Java是没有完整的集合框架的。它只有一些简单的可以自扩展的容器类。但是在Java2后他们还是被融入到了集合框架的,不过只是历史遗留而已。它们和1.2前应该还是有些变化的,虽然本质没什么变化。Set接口继承于Collection,但不允许重复,使用自己内部的一个排列机制。List接口继承Collection,允许重复,以元素安插的次序来放置元素,不会重新排列。Map接口是一组成对的键-值对象,即所持有的是key-value pairs。Map中不能有重复的key。拥有自己的内部排列机制。一、Java1.2之前的容器类库其实在Java2之前,Java是没有完整的集合框架的。它只有一些简单的可以自扩展的容器类,比如Vector,Stack,Hashtable等。Java1容器类库设计的一个重大失误是竟然没有对容器进行排序的工具。比如你想让Vector容器中的对象按字典顺序进行排序,你就要自己实现。1.1、Vectorjava.util.Vector中包含的元素可以通过一个整型的索引值取得,它的大小可以在添加或移除元素时自动增加或缩小。Vector的操作很简单,通过addElement()加入一个对象,用elementAt()取出它,还可以查询当前所保存的对象的个数size();另外还有一个Enumeration类提供了连续操作Vector中元素的方法,这可以通过Vector中的elements()方法来获取一个Enumeration类的对象,可以用一个While循环来遍历其中的元素。用hasMoreElements()检查其中是否还有更多的元素。用nextElement()获得下一个元素。Enumeration的用意在于使你能完全不用理会你要遍历的容器的基础结构,只关注你的遍历方法,这也就使得遍历方法的重用成为可能。由于这种思想的强大功能,所以在Java2中被保留下来,不过具体实现,方法名和内部算法都改变了,这就是Java2中的Iterator以及ListIterator类。然而Enumeration的功能却十分有限,比如只能朝一个方向进行,只能读取而不能更改等。更多内容请参考《Vector》1.2、Stackjava.util.Stack最常用的操作便是压入和弹出,最后压入的元素最先被弹出。它遵循后进先出(LIFO)原则。在Java中Stack的的用法也很简单,有push()压入一个元素,用pop()弹出一个元素。更多内容请参考《Stack容器》1.3、HashtableHashtable与Java2中的Map类似,可以看成一种关联或映射数组,可以将两个毫无关系的对象相关联。它的基本目标是实现两个对象之间进行关联。更多内容请参考《Hashtable》二、Java2中的容器类库自Java1.2之后Java版本统称为Java2,Java2中的容器类库才可以说是一种真正意义上的集合框架的实现。基本完全重新设计,但是又对Java1中的一些容器类库在新的设计上进行了保留,这主要是为了向下兼容的目的,当用 Java2开发程序时,应尽量避免使用它们,Java2的集合框架已经完全可以满足你的需求。在Java1中容器类库是同步化的,而 Java2中的容器类库都是非同步化,这可能是对执行效率进行考虑的结果。Java2中的集合框架提供了一套设计优良的接口和类,使程序员操作成批的数据或对象元素极为方便。这些接口和类有很多对抽象数据类型操作的API,而这是我们常用的且在数据结构中熟知的。例如Maps,Sets,Lists,Arrays等。并且Java用面向对象的设计对这些数据结构和算法进行了封装,这就极大的减化了程序员编程时的负担。程序员也可以以这个集合框架为基础,定义更高级别的数据抽象,比如栈、队列和线程安全的集合等,从而满足自己的需要。Java2的集合框架,抽其核心,主要有三类:List(包括List,Queue,BlockingQueue)、Set和Map。List和Set继承了Collection,而Map则独成一体。初看上去可能会对Map独成一体感到不解,它为什么不也继承Collection呢?但是这种设计是合理的。一个Map提供了通过Key对Map中存储的Value进行访问,也就是说它操作的都是成对的对象元素,比如put()和get()方法,而这是一个Set或List 所不就具备的。当然在需要时,你可以由keySet()方法或values()方法从一个Map中得到键的Set集或值的Collection集。集合框架中还有两个很实用的公用类:Collections和Arrays。Collections提供了对一个Collection容器进行诸如排序、复制、查找和填充等一些非常有用的方法, Arrays则是对一个数组进行类似的操作。2.1、CollectionCollection接口提供了一组操作成批对象的方法。(它只是个接口)它提供了基本操作如添加、删除。它也支持查询操作如是否为空isEmpty()方法等。为了支持对Collection进行独立操作,Java的集合框架给出了一个Iterator,它使得你可以泛型操作一个Collection,而不需知道这个 Collection的具体实现类型是什么。它的功能与Java1中的Enumeration类似,只是更易掌握和使用,功能也更强大。在建立集合框架时,Sun的开发团队考虑到需要提供一些灵活的接口,用来操作成批的元素,又为了设计的简便,就把那些对集合进行可选操作的方法与基本方法放到了一起。因为一个接口的实现者必须提供对接口中定义的所有方法的实现,这就需要一种途径让调用者知道它正在调用 的可选方法当前不支持。最后开发团队选择使用一种信号,也即抛出一种不支持操作例外(UnsupportedOperationException),如果你在使用一个Collection中遇到一个上述的例外,那就意味着你的操作失败,比如你对一个只读Collection添加一个元素时,你就会得到一个不支持操作例外。在你实现一个集合接口时,你可以很容易的在你不想让用户使用的方法中抛出UnsupportOperationException来告诉使用者这个方法当前没有实现,UnsupportOperationException是RuntimeException的一个扩展。另外Java2的容器类库还有一种Fail fast的机制。比如你正在用一个Iterator遍历一个容器中的对象,这时另外一个线程或进程对那个容器进行了修改,那么再用next()方法时可能会有灾难性的后果,而这是你不愿看到的,这时就会引发一个ConcurrentModificationException例外。这就是 fail-fast。

51干警网 2019-12-02 01:42:48 0 浏览量 回答数 0

回答

你好,这里有208份资料,详情请参考:https://github.com/ty4z2008/Qix/blob/master/ds.md 《Reconfigurable Distributed Storage for Dynamic Networks》介绍:这是一篇介绍在动态网络里面实现分布式系统重构的paper.论文的作者(导师)是MIT读博的时候是做分布式系统的研究的,现在在NUS带学生,不仅仅是分布式系统,还有无线网络.如果感兴趣可以去他的主页了解. 《Distributed porgramming liboratory》介绍:分布式编程实验室,他们发表的很多的paper,其中不仅仅是学术研究,还有一些工业界应用的论文. 《MIT Theory of Distributed Systems》介绍:麻省理工的分布式系统理论主页,作者南希·林奇在2002年证明了CAP理论,并且著《分布式算法》一书. 《Notes on Distributed Systems for Young Bloods》介绍:分布式系统搭建初期的一些建议 《Principles of Distributed Computing》介绍:分布式计算原理课程 《Google's Globally-Distributed Database》介绍:Google全球分布式数据介绍,中文版 《The Architecture Of Algolia’s Distributed Search Network》介绍:Algolia的分布式搜索网络的体系架构介绍 《Build up a High Availability Distributed Key-Value Store》介绍:构建高可用分布式Key-Value存储系统 《Distributed Search Engine with Nanomsg and Bond》介绍:Nanomsg和Bond的分布式搜索引擎 《Distributed Processing With MongoDB And Mongothon》介绍:使用MongoDB和Mongothon进行分布式处理 《Salt: Combining ACID and BASE in a Distributed Database》介绍:分布式数据库中把ACID与BASE结合使用. 《Makes it easy to understand Paxos for Distributed Systems》介绍:理解的Paxos的分布式系统,参考阅读:关于Paxos的历史 《There is No Now Problems with simultaneity in distributed systems》介绍:There is No Now Problems with simultaneity in distributed systems 《Distributed Systems》介绍:伦敦大学学院分布式系统课程课件. 《Distributed systems for fun and profit》介绍:分布式系统电子书籍. 《Distributed Systems Spring 2015》介绍:卡内基梅隆大学春季分布式课程主页 《Distributed Systems: Concepts and Design (5th Edition)》介绍: 电子书,分布式系统概念与设计(第五版) 《走向分布式》介绍:这是一位台湾网友 ccshih 的文字,短短的篇幅介绍了分布式系统的若干要点。pdf 《Introduction to Distributed Systems Spring 2013》介绍:清华大学分布式系统课程主页,里面的schedule栏目有很多宝贵的资源 《Distributed systems》介绍:免费的在线分布式系统书籍 《Some good resources for learning about distributed computing》介绍:Quora上面的一篇关于学习分布式计算的资源. 《Spanner: Google’s Globally-Distributed Database》介绍:这个是第一个全球意义上的分布式数据库,也是Google的作品。其中介绍了很多一致性方面的设计考虑,为了简单的逻辑设计,还采用了原子钟,同样在分布式系统方面具有很强的借鉴意义. 《The Chubby lock service for loosely-coupled distributed systems》介绍:Google的统面向松散耦合的分布式系统的锁服务,这篇论文详细介绍了Google的分布式锁实现机制Chubby。Chubby是一个基于文件实现的分布式锁,Google的Bigtable、Mapreduce和Spanner服务都是在这个基础上构建的,所以Chubby实际上是Google分布式事务的基础,具有非常高的参考价值。另外,著名的zookeeper就是基于Chubby的开源实现.推荐The google stack,Youtube:The Chubby lock service for loosely-coupled distributed systems 《Sinfonia: a new paradigm for building scalable distributed systems》介绍:这篇论文是SOSP2007的Best Paper,阐述了一种构建分布式文件系统的范式方法,个人感觉非常有用。淘宝在构建TFS、OceanBase和Tair这些系统时都充分参考了这篇论文. 《Data-Intensive Text Processing with MapReduce》介绍:Ebook:Data-Intensive Text Processing with MapReduce. 《Design and Implementation of a Query Processor for a Trusted Distributed Data Base Management System》介绍:Design and Implementation of a Query Processor for a Trusted Distributed Data Base Management System. 《Distributed Query Processing》介绍:分布式查询入门. 《Distributed Systems and the End of the API》介绍:分布式系统和api总结. 《Distributed Query Reading》介绍:分布式系统阅读论文,此外还推荐github上面的一个论文列表The Distributed Reader。 《Replication, atomicity and order in distributed systems》介绍:Replication, atomicity and order in distributed systems 《MIT course:Distributed Systems》介绍:2015年MIT分布式系统课程主页,这次用Golang作为授课语言。6.824 Distributed Systems课程主页 《Distributed systems for fun and profit》介绍:免费分布式系统电子书。 《Ori:A Secure Distributed File System》介绍:斯坦福开源的分布式文件系统。 《Availability in Globally Distributed Storage Systems》介绍:Google论文:设计一个高可用的全球分布式存储系统。 《Calvin: Fast Distributed Transactions For Partitioned Database Systems》介绍:对于分区数据库的分布式事务处理。 《Distributed Systems Building Block: Flake Ids》介绍:Distributed Systems Building Block: Flake Ids. 《Introduction to Distributed System Design》介绍:Google Code University课程,如何设计一个分布式系统。 《Sheepdog: Distributed Storage System for KVM》介绍:KVM的分布式存储系统. 《Readings in Distributed Systems Systems》介绍:分布式系统课程列表,包括数据库、算法等. 《Tera》介绍:来自百度的分布式表格系统. 《Distributed systems: for fun and profit》介绍:分布式系统的在线电子书. 《Distributed Systems Reading List》介绍:分布式系统资料,此外还推荐Various articles about distributed systems. 《Designs, Lessons and Advice from Building Large Distributed Systems》介绍:Designs, Lessons and Advice from Building Large Distributed Systems. 《Testing a Distributed System》介绍:Testing a distributed system can be trying even under the best of circumstances. 《The Google File System》介绍: 基于普通服务器构建超大规模文件系统的典型案例,主要面向大文件和批处理系统, 设计简单而实用。 GFS是google的重要基础设施, 大数据的基石, 也是Hadoop HDFS的参考对象。 主要技术特点包括: 假设硬件故障是常态(容错能力强), 64MB大块, 单Master设计,Lease/链式复制, 支持追加写不支持随机写. 《Bigtable: A Distributed Storage System for Structured Data》介绍:支持PB数据量级的多维非关系型大表, 在google内部应用广泛,大数据的奠基作品之一 , Hbase就是参考BigTable设计。 Bigtable的主要技术特点包括: 基于GFS实现数据高可靠, 使用非原地更新技术(LSM树)实现数据修改, 通过range分区并实现自动伸缩等.中文版 《PacificA: Replication in Log-Based Distributed Storage Systems》介绍:面向log-based存储的强一致的主从复制协议, 具有较强实用性。 这篇文章系统地讲述了主从复制系统应该考虑的问题, 能加深对主从强一致复制的理解程度。 技术特点: 支持强一致主从复制协议, 允许多种存储实现, 分布式的故障检测/Lease/集群成员管理方法. 《Object Storage on CRAQ, High-throughput chain replication for read-mostly workloads》介绍:分布式存储论文:支持强一直的链式复制方法, 支持从多个副本读取数据,实现code. 《Finding a needle in Haystack: Facebook’s photo storage》介绍:Facebook分布式Blob存储,主要用于存储图片. 主要技术特色:小文件合并成大文件,小文件元数据放在内存因此读写只需一次IO. 《Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency》介绍: 微软的分布式存储平台, 除了支持类S3对象存储,还支持表格、队列等数据模型. 主要技术特点:采用Stream/Partition两层设计(类似BigTable);写错(写满)就封存Extent,使得副本字节一致, 简化了选主和恢复操作; 将S3对象存储、表格、队列、块设备等融入到统一的底层存储架构中. 《Paxos Made Live – An Engineering Perspective》介绍:从工程实现角度说明了Paxo在chubby系统的应用, 是理解Paxo协议及其应用场景的必备论文。 主要技术特点: paxo协议, replicated log, multi-paxo.参考阅读:关于Paxos的历史 《Dynamo: Amazon’s Highly Available Key-Value Store》介绍:Amazon设计的高可用的kv系统,主要技术特点:综和运用一致性哈希,vector clock,最终一致性构建一个高可用的kv系统, 可应用于amazon购物车场景.新内容来自分布式存储必读论文 《Efficient Replica Maintenance for Distributed Storage Systems》介绍:分布式存储系统中的副本存储问题. 《PADS: A Policy Architecture for Distributed Storage Systems》介绍:分布式存储系统架构. 《The Chirp Distributed Filesystem》介绍:开源分布式文件系统Chirp,对于想深入研究的开发者可以阅读文章的相关Papers. 《Time, Clocks, and the Ordering of Events in a Distributed System》介绍:经典论文分布式时钟顺序的实现原理. 《Making reliable distributed systems in the presence of sodware errors》介绍:面向软件错误构建可靠的分布式系统,中文笔记. 《MapReduce: Simplified Data Processing on Large Clusters》介绍:MapReduce:超大集群的简单数据处理. 《Distributed Computer Systems Engineering》介绍:麻省理工的分布式计算课程主页,里面的ppt和阅读列表很多干货. 《The Styx Architecture for Distributed Systems》介绍:分布式系统Styx的架构剖析. 《What are some good resources for learning about distributed computing? Why?》介绍:Quora上面的一个问答:有哪些关于分布式计算学习的好资源. 《RebornDB: The Next Generation Distributed Key-Value Store》介绍:下一代分布式k-v存储数据库. 《Operating System Concepts Ninth Edition》介绍:分布式系统归根结底还是需要操作系统的知识,这是耶鲁大学的操作系统概念书籍首页,里面有提供了第8版的在线电子版和最新的学习操作系统指南,学习分布式最好先学习操作系统. 《The Log: What every software engineer should know about real-time data's unifying abstraction》介绍:分布式系统Log剖析,非常的详细与精彩. 中文翻译 | 中文版笔记. 《Operating Systems Study Guide》介绍:分布式系统基础之操作系统学习指南. 《分布式系统领域经典论文翻译集》介绍:分布式系统领域经典论文翻译集. 《Maintaining performance in distributed systems》介绍:分布式系统性能维护. 《Computer Science from the Bottom Up》介绍:计算机科学,自底向上,小到机器码,大到操作系统内部体系架构,学习操作系统的另一个在线好材料. 《Operating Systems: Three Easy Pieces》介绍:<操作系统:三部曲>在线电子书,虚拟、并发、持续. 《Database Systems: reading list》介绍:数据库系统经典论文阅读列,此外推送github上面的db reading. 《Unix System Administration》介绍:Unix System Administration ebook. 《The Amoeba Distributed Operating System》介绍:分布式系统经典论文. 《Principles of Computer Systems》介绍:计算机系统概念,以分布式为主.此外推荐Introduction to Operating Systems笔记 《Person page of EMİN GÜN SİRER》介绍:推荐康奈尔大学的教授EMİN GÜN SİRER的主页,他的研究项目有分布式,数据存储。例如HyperDex数据库就是他的其中一个项目之一. 《Scalable, Secure, and Highly Available Distributed File Access》介绍:来自卡内基梅隆如何构建可扩展的、安全、高可用性的分布式文件系统,其他papers. 《Distributed (Deep) Machine Learning Common》介绍:分布式机器学习常用库. 《The Datacenter as a Computer》介绍:介绍了如何构建仓储式数据中心,尤其是对于现在的云计算,分布式学习来说很有帮助.本书是Synthesis Lectures on Computer Architecture系列的书籍之一,这套丛书还有 《The Memory System》,《Automatic Parallelization》,《Computer Architecture Techniques for Power Efficiency》,《Performance Analysis and Tuning for General Purpose Graphics Processing Units》,《Introduction to Reconfigurable Supercomputing》,Memory Systems Cache, DRAM, Disk 等 《helsinki:Distributed Systems Course slider》介绍:来自芬兰赫尔辛基的分布式系统课程课件:什么是分布式,复制,一致性,容错,同步,通信. 《TiDB is a distributed SQL database》介绍:分布式数据库TiDB,Golang开发. 《S897: Large-Scale Systems》介绍:课程资料:大规模系统. 《Large-scale L-BFGS using MapReduce》介绍:使用MapReduce进行大规模分布式集群环境下并行L-BFGS. 《Twitter是如何构建高性能分布式日志的》介绍:Twitter是如何构建高性能分布式日志的. 《Distributed Systems: When Limping Hardware Is Worse Than Dead Hardware》介绍:在分布式系统中某个组件彻底死了影响很小,但半死不活(网络/磁盘),对整个系统却是毁灭性的. 《Tera - 高性能、可伸缩的结构化数据库》介绍:来自百度的分布式数据库. 《SequoiaDB is a distributed document-oriented NoSQL Database》介绍:SequoiaDB分布式文档数据库开源. 《Readings in distributed systems》介绍:这个网址里收集了一堆各TOP大学分布式相关的课程. 《Paxos vs Raft》介绍:这个网站是Raft算法的作者为教授Paxos和Raft算法做的,其中有两个视频链接,分别讲上述两个算法.参考阅读:关于Paxos的历史 《A Scalable Content-Addressable Network》介绍:A Scalable Content-Addressable Network. 《500 Lines or Less》介绍:这个项目其实是一本书( The Architecture of Open Source Applications)的源代码附录,是一堆大牛合写的. 《MIT 6.824 Distributed System》介绍:这只是一个课程主页,没有上课的视频,但是并不影响你跟着它上课:每一周读两篇课程指定的论文,读完之后看lecture-notes里对该论文内容的讨论,回答里面的问题来加深理解,最后在课程lab里把所看的论文实现。当你把这门课的作业刷完后,你会发现自己实现了一个分布式数据库. 《HDFS-alike in Go》介绍:使用go开发的分布式文件系统. 《What are some good resources for learning about distributed computing? Why?》介绍:Quora上关于学习分布式的资源问答. 《SeaweedFS is a simple and highly scalable distributed file system》介绍:SeaweedFS是使用go开发的分布式文件系统项目,代码简单,逻辑清晰. 《Codis - yet another fast distributed solution for Redis》介绍:Codis 是一个分布式 Redis 解决方案, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有明显的区别 《Paper: Coordination Avoidance In Distributed Databases By Peter Bailis》介绍:Coordination Avoidance In Distributed Databases. 《从零开始写分布式数据库》介绍:本文以TiDB 源码为例. 《what we talk about when we talk about distributed systems》介绍:分布式系统概念梳理,为分布式系统涉及的主要概念进行了梳理. 《Distributed locks with Redis》介绍:使用Redis实现分布式锁. 《CS244b: Distributed Systems》介绍: 斯坦福2014年秋季分布式课程. 《RAMP Made Easy》介绍: 分布式的“读原子性”. 《Strategies and Principles of Distributed Machine Learning on Big Data》介绍: 大数据分布式机器学习的策略与原理. 《Distributed Systems: What is the CAP theorem?》介绍: 分布式CAP法则. 《How should I start to learn distributed storage system as a beginner?》介绍: 新手如何步入分布式存储系统. 《Cassandra - A Decentralized Structured Storage System》介绍: 分布式存储系统Cassandra剖析,推荐白皮书Introduction to Apache Cassandra. 《What is the best resource to learn about distributed systems?》介绍: 分布式系统学习资源. 《What are some high performance TCP hacks?》介绍: 一些高性能TCP黑客技巧. 《Maintaining performance in distributed systems》介绍:分布式系统性能提升. 《A simple totally ordered broadcast protocol》介绍:Benjamin Reed 和 Flavio P.Junqueira 所著论文,对Zab算法进行了介绍,zab算法是Zookeeper保持数据一致性的核心,在国内有很多公司都使用zookeeper做为分布式的解决方案.推荐与此相关的一篇文章ZooKeeper’s atomic broadcast protocol: Theory and practice. 《zFS - A Scalable Distributed File System Using Object Disk》介绍:可扩展的分布式文件系统ZFS,The Zettabyte File System,End-to-end Data Integrity for File Systems: A ZFS Case Study. 《A Distributed Haskell for the Modern Web》介绍:分布式Haskell在当前web中的应用. 《Reasoning about Consistency Choices in Distributed Systems》介绍:POPL2016的论文,关于分布式系统一致性选择的论述,POPL所接受的论文,github上已经有人整理. 《Paxos Made Simple》介绍:Paxos让分布式更简单.译文.参考阅读:关于Paxos的历史,understanding Paxos part1,Understanding Paxos – Part 2.Quora: What is a simple explanation of the Paxos algorithm?,Tutorial Summary: Paxos Explained from Scratch,Paxos algorithm explained, part 1: The essentials,Paxos algorithm explained, part 2: Insights 《Consensus Protocols: Paxos》介绍:分布式系统一致性协议:Paxos.参考阅读:关于Paxos的历史 《Consensus on Transaction Commit》介绍:事务提交的一致性探讨. 《The Part-Time Parliaments》介绍:在《The Part-Time Parliament》中描述了基本协议的交互过程。在基本协议的基础上完善各种问题得到了最终的议会协议。 为了让人更容易理解《The Part-Time Parliament》中描述的Paxos算法,Lamport在2001发表了《Paxos Made Simple》,以更平直的口头语言描述了Paxos,而没有包含正式的证明和数学术语。《Paxos Made Simple》中,将算法的参与者更细致的划分成了几个角色:Proposer、Acceptor、Learner。另外还有Leader和Client.参考阅读:关于Paxos的历史 《Paxos Made Practical》介绍:看这篇论文时可以先看看理解Paxos Made Practical. 《PaxosLease: Diskless Paxos for Leases》介绍:PaxosLease:实现租约的无盘Paxos算法,译文. 《Paxos Made Moderately Complex》介绍:Paxos算法实现,译文,同时推荐42 Paxos Made Moderately Complex. 《Hadoop Reading List》介绍:Hadoop学习清单. 《Hadoop Reading List》介绍:Hadoop学习清单. 《2010 NoSQL Summer Reading List》介绍:NoSQL知识清单,里面不仅仅包含了数据库阅读清单还包含了分布式系统资料. 《Raft: Understandable Distributed Consensus》介绍:Raft可视化图帮助理解分布式一致性 《Etcd:Distributed reliable key-value store for the most critical data of a distributed system》介绍:Etcd分布式Key-Value存储引擎 《Understanding Availability》介绍:理解peer-to-peer系统中的可用性究竟是指什么.同时推荐基于 Peer-to-Peer 的分布式存储系统的设计 《Process structuring, synchronization, and recovery using atomic actions》介绍:经典论文 《Programming Languages for Parallel Processing》介绍:并行处理的编程语音 《Analysis of Six Distributed File Systems》介绍:此篇论文对HDFS,MooseFS,iRODS,Ceph,GlusterFS,Lustre六个存储系统做了详细分析.如果是自己研发对应的存储系统推荐先阅读此篇论文 《A Survey of Distributed File Systems》介绍:分布式文件系统综述 《Concepts of Concurrent Programming》介绍:并行编程的概念,同时推荐卡内基梅隆FTP 《Concurrency Control Performance Modeling:Alternatives and Implications》介绍:并发控制性能建模:选择与意义 《Distributed Systems - Concepts and Design 5th Edition》介绍:ebook分布式系统概念与设计 《分布式系统设计的形式方法》介绍:分布式系统设计的形式方法 《互斥和选举算法》介绍:互斥和选举算法 《Actors:A model Of Concurrent Cornputation In Distributed Systems》介绍:经典论文 《Security Engineering: A Guide to Building Dependable Distributed Systems》介绍:如何构建一个安全可靠的分布式系统,About the Author,Bibliography:文献资料,章节访问把链接最后的01换成01-27即可 《15-712 Advanced and Distributed Operating Systems》介绍:卡内基梅隆大学的分布式系统博士生课程主页,有很丰富的资料 《Dapper, Google's Large-Scale Distributed Systems Tracing Infrastructure》介绍:Dapper,大规模分布式系统的跟踪系统,译文,译文对照 《CS262a: Advanced Topics in Computer Systems》介绍:伯克利大学计算机系统进阶课程,内容有深度,涵盖分布式,数据库等内容 《Egnyte Architecture: Lessons Learned In Building And Scaling A Multi Petabyte Distributed System》介绍:PB级分布式系统构建/扩展经验 《CS162: Operating Systems and Systems Programming》介绍:伯克利大学计算机系统课程:操作系统与系统编程 《MDCC: Multi-Data Center Consistency》介绍:MDCC主要解决跨数据中心的一致性问题中间件,一种新的协议 《Research at Google:Distributed Systems and Parallel Computing》介绍:google公开对外发表的分布式系统与并行计算论文 《HDFS Architecture Guide》介绍:分布式文件系统HDFS架构 《ActorDB distributed SQL database》介绍:分布式 Key/Value数据库 《An efficient data location protocol for self-organizing storage clusters》介绍:是著名的Ceph的负载平衡策略,文中提出的几种策略都值得尝试,比较赞的一点是可以对照代码体会和实践,如果你还需要了解可以看看Ceph:一个 Linux PB 级分布式文件系统,除此以外,论文的引用部分也挺值得阅读的,同时推荐Ceph: A Scalable, High-Performance Distributed File System 《A Self-Organizing Storage Cluster for Parallel Data-Intensive Applications》介绍:Surrento的冷热平衡策略就采用了延迟写技术 《HBA: Distributed Metadata Management for Large Cluster-Based Storage Systems》介绍:对于分布式存储系统的元数据管理. 《Server-Side I/O Coordination for Parallel File Systems》介绍:服务器端的I/O协调并行文件系统处理,网络,文件存储等都会涉及到IO操作.不过里面涉及到很多技巧性的思路在实践时需要斟酌 《Distributed File Systems: Concepts and Examples》介绍:分布式文件系统概念与应用 《CSE 221: Graduate Operating Systems》介绍:加利福尼亚大学的研究生操作系统课程主页,论文很值得阅读 《S4: Distributed Stream Computing Platform》介绍:Yahoo出品的流式计算系统,目前最流行的两大流式计算系统之一(另一个是storm),Yahoo的主要广告计算平台 《Pregel: a system for large-scale graph processing》介绍:Google的大规模图计算系统,相当长一段时间是Google PageRank的主要计算系统,对开源的影响也很大(包括GraphLab和GraphChi) 《GraphLab: A New Framework for Parallel Machine Learning》介绍:CMU基于图计算的分布式机器学习框架,目前已经成立了专门的商业公司,在分布式机器学习上很有两把刷子,其单机版的GraphChi在百万维度的矩阵分解都只需要2~3分钟; 《F1: A Distributed SQL Database That Scales》介绍:这篇论文是Google 2013年发表的,介绍了F1的架构思路,13年时就开始支撑Google的AdWords业务,另外两篇介绍文章F1 - The Fault-Tolerant Distributed RDBMS Supporting Google's Ad Business .Google NewSQL之F1 《Cockroach DB:A Scalable, Survivable, Strongly-Consistent SQL Database》介绍:CockroachDB :一个可伸缩的、跨地域复制的,且支持事务的数据存储,InfoQ介绍,Design and Architecture of CockroachDb 《Multi-Paxos: An Implementation and Evaluation》介绍:Multi-Paxos实现与总结,此外推荐Paxos/Multi-paxos Algorithm,Multi-Paxos Example,地址:ftp://ftp.cs.washington.edu/tr/2009/09/UW-CSE-09-09-02.PDF 《Zab: High-performance broadcast for primary-backup systems》介绍:一致性协议zab分析 《A Distributed Hash Table》介绍:分布式哈希算法论文,扩展阅读Introduction to Distributed Hash Tables,Distributed Hash Tables 《Comparing the performance of distributed hash tables under churn》介绍:分布式hash表性能的Churn问题 《Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web》介绍:分布式系统的CAP问题,推荐Perspectives on the CAP Theorem.对CAP理论的解析文章,PODC ppt,A plain english introduction to CAP Theorem,IEEE Computer issue on the CAP Theorem 《F2FS: A New File System for Flash Storage》介绍:闪存存储文件系统F2FS 《Better I/O Through Byte-Addressable, Persistent Memory》介绍:微软发表的关于i/o访问优化论文 《tmpfs: A Virtual Memory File System》介绍:虚拟内存文件系统tmpfs 《BTRFS: The Linux B-tree Filesystem》介绍:Linux B-tree文件系统. 《Akamai technical publication》介绍:Akamai是全球最大的云计算机平台之一,承载了全球15-30%网络流量,如果你是做CDN或者是云服务,这个里面的论文会给你很有帮助.例如这几天看facebook开源的osquery。找到通过db的方式运维,找到Keeping Track of 70,000+ Servers: The Akamai Query System这篇论文,先看论文领会思想,然后再使用工具osquery实践 《BASE: An Acid Alternative》介绍:来自eBay 的解决方案,译文Base: 一种Acid的替代方案,应用案例参考保证分布式系统数据一致性的6种方案 《A Note on Distributed Computing》介绍:Jim Waldo和Sam Kendall等人共同撰写了一篇非常有名的论文“分布式计算备忘录”,这篇论文在Reddit上被人推荐为“每个程序员都应当至少读上两篇”的论文。在这篇论文中,作者表示“忽略本地计算与分布式计算之间的区别是一种危险的思想”,特别指出了Emerald、Argus、DCOM以及CORBA的设计问题。作者将这些设计问题归纳为“三个错误的原则”: “对于某个应用来说,无论它的部署环境如何,总有一种单一的、自然的面向对象设计可以符合其需求。” “故障与性能问题与某个应用的组件实现直接相关,在最初的设计中无需考虑这些问题。” “对象的接口与使用对象的上下文无关”. 《Distributed Systems Papers》介绍:分布式系统领域经典论文列表. 《Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web》介绍:Consistent Hashing算法描述. 《SIGMOD 2016: Accepted Research Papers》介绍:SIGMOD是世界上最有名的数据库会议之一,最具有权威性,收录论文审核非常严格.2016年的SIGMOD 会议照常进行,上面收录了今年SIGMOD收录的论文,把题目输入google中加上pdf就能找到,很多论文值得阅读,SIGMOD 2015 《Notes on CPSC 465/565: Theory of Distributed Systems》介绍:耶鲁大学的分布式系统理论课程笔记 《Distributed Operating System Doc PDF》介绍:分布式系统文档资源(可下载) 《Anatomy of a database system》介绍:数据库系统剖析,这本书是由伯克利大学的Joseph M. Hellerstein和M. Stonebraker合著的一篇论文.对数据库剖析很有深度.除此以外还有一篇文章Architecture of a Database System。数据库系统架构,厦门大学的数据库实验室教授林子雨组织过翻译 《A Relational Model of Data for Large Shared Data Banks》介绍:数据库关系模型论文 《RUC Innovative data systems reaserch lab recommand papers》介绍:中国人民大学数据研究实验室推荐的数据库领域论文 《A Scalable Distributed Information Management System》介绍:构建可扩展的分布式信息管理系统 《Distributed Systems in Haskell》介绍:Haskell中的分布式系统开发 《Large-scale cluster management at Google with Borg》介绍:Google使用Borg进行大规模集群的管理,伯克利大学ppt介绍,中文版 《Lock Free Programming Practice》介绍:并发编程(Concurrency Programming)资料,主要涵盖lock free数据结构实现、内存回收方法、memory model等备份链接 密码: xc5j 《Distributed Algorithms Lecture Notes for 6.852》介绍:Nancy Lynch's的分布式算法研究生课程讲义 《Distributed Algorithms for Topic Models》介绍:分布式算法主题模型. 《RecSys - ACM Recommender Systems》介绍:世界上非常有名的推荐系统会议,我比较推荐接收的PAPER 《All Things Distributed》介绍:推荐一个博客,博主是Amazon CTO Werner Vogels,这是一个关注分布式领域的博客.大部分博文是关于在工业界应用. 《programming, database, distributed system resource list》介绍:这个Git是由阿里(alibaba)的技术专家何登成维护,主要是分布式数据库. 《Making reliable distributed systems in the presence of sodware errors》介绍:Erlang的作者Joe Armstrong撰写的论文,面对软件错误构建可靠的分布式系统.中文译版 《CS 525: Advanced Distributed Systems[Spring 2016]》介绍:伊利诺伊大学的Advanced Distributed Systems 里把各个方向重要papers(updated Spring 2015)列举出来,可以参考一下 《Distributed Algorithms》介绍:这是一本分布式算法电子书,作者是Jukka Suomela.讲述了多个计算模型,一致性,唯一标示,并发等. 《TinyLFU: A Highly Efficient Cache Admission Policy》介绍:当时是在阅读如何设计一个缓存系统时看到的,然后通过Google找到了这一篇关于缓存策略的论文,它是LFU的改良版,中文介绍.如果有兴趣可以看看Golang实现版。结合起来可能会帮助你理解 《6.S897: Large-Scale Systems》介绍:斯坦福大学给研究生开的分布式系统课程。教师是 spark 作者 matei. 能把这些内容真正理解透,分布式系统的功力就很强了。 《学习分布式系统需要怎样的知识?》介绍:[怎么学系列]学习分布式系统需要怎样的知识? 《Distributed systems theory for the distributed systems engineer》介绍:分布式系统工程师的分布式系统理论 《A Distributed Systems Reading List》介绍:分布式系统论文阅读列表 《Distributed Systems Reading Group》介绍:麻省理工大学分布式系统小组,他们会把平时阅读到的优秀论文分享出来。虽然有些论文本页已经收录,但是里面的安排表schedule还是挺赞的 《Scalable Software Architecture》介绍:分布式系统、可扩展性与系统设计相关报告、论文与网络资源汇总. 《MapReduce&Hadoop resource》介绍:MapReduce&Hadoop相关论文,涉及分布式系统设计,性能分析,实践,优化等多个方面 《Distributed Systems: Principles and Paradigms(second edtion)》介绍:分布式系统原理与范型第二版,课后解答 《Distributed Systems Seminar's reading list for Spring 2017》介绍:分布式系统研讨会论文阅读列表 《A Critique of the CAP Theorem》介绍:这是一篇评论CAP定理的论文,学习CAP很有帮助,推荐阅读评论文章"A Critique of the CAP Theorem" 《Evolving Distributed Systems》介绍:推荐文章不断进化的分布式系统.

suonayi 2019-12-02 03:17:27 0 浏览量 回答数 0

回答

92题 一般来说,建立INDEX有以下益处:提高查询效率;建立唯一索引以保证数据的唯一性;设计INDEX避免排序。 缺点,INDEX的维护有以下开销:叶节点的‘分裂’消耗;INSERT、DELETE和UPDATE操作在INDEX上的维护开销;有存储要求;其他日常维护的消耗:对恢复的影响,重组的影响。 需要建立索引的情况:为了建立分区数据库的PATITION INDEX必须建立; 为了保证数据约束性需要而建立的INDEX必须建立; 为了提高查询效率,则考虑建立(是否建立要考虑相关性能及维护开销); 考虑在使用UNION,DISTINCT,GROUP BY,ORDER BY等字句的列上加索引。 91题 作用:加快查询速度。原则:(1) 如果某属性或属性组经常出现在查询条件中,考虑为该属性或属性组建立索引;(2) 如果某个属性常作为最大值和最小值等聚集函数的参数,考虑为该属性建立索引;(3) 如果某属性经常出现在连接操作的连接条件中,考虑为该属性或属性组建立索引。 90题 快照Snapshot是一个文件系统在特定时间里的镜像,对于在线实时数据备份非常有用。快照对于拥有不能停止的应用或具有常打开文件的文件系统的备份非常重要。对于只能提供一个非常短的备份时间而言,快照能保证系统的完整性。 89题 游标用于定位结果集的行,通过判断全局变量@@FETCH_STATUS可以判断是否到了最后,通常此变量不等于0表示出错或到了最后。 88题 事前触发器运行于触发事件发生之前,而事后触发器运行于触发事件发生之后。通常事前触发器可以获取事件之前和新的字段值。语句级触发器可以在语句执行前或后执行,而行级触发在触发器所影响的每一行触发一次。 87题 MySQL可以使用多个字段同时建立一个索引,叫做联合索引。在联合索引中,如果想要命中索引,需要按照建立索引时的字段顺序挨个使用,否则无法命中索引。具体原因为:MySQL使用索引时需要索引有序,假设现在建立了"name,age,school"的联合索引,那么索引的排序为: 先按照name排序,如果name相同,则按照age排序,如果age的值也相等,则按照school进行排序。因此在建立联合索引的时候应该注意索引列的顺序,一般情况下,将查询需求频繁或者字段选择性高的列放在前面。此外可以根据特例的查询或者表结构进行单独的调整。 86题 建立索引的时候一般要考虑到字段的使用频率,经常作为条件进行查询的字段比较适合。如果需要建立联合索引的话,还需要考虑联合索引中的顺序。此外也要考虑其他方面,比如防止过多的所有对表造成太大的压力。这些都和实际的表结构以及查询方式有关。 85题 存储过程是一组Transact-SQL语句,在一次编译后可以执行多次。因为不必重新编译Transact-SQL语句,所以执行存储过程可以提高性能。触发器是一种特殊类型的存储过程,不由用户直接调用。创建触发器时会对其进行定义,以便在对特定表或列作特定类型的数据修改时执行。 84题 存储过程是用户定义的一系列SQL语句的集合,涉及特定表或其它对象的任务,用户可以调用存储过程,而函数通常是数据库已定义的方法,它接收参数并返回某种类型的值并且不涉及特定用户表。 83题 减少表连接,减少复杂 SQL,拆分成简单SQL。减少排序:非必要不排序,利用索引排序,减少参与排序的记录数。尽量避免 select *。尽量用 join 代替子查询。尽量少使用 or,使用 in 或者 union(union all) 代替。尽量用 union all 代替 union。尽量早的将无用数据过滤:选择更优的索引,先分页再Join…。避免类型转换:索引失效。优先优化高并发的 SQL,而不是执行频率低某些“大”SQL。从全局出发优化,而不是片面调整。尽可能对每一条SQL进行 explain。 82题 如果条件中有or,即使其中有条件带索引也不会使用(要想使用or,又想让索引生效,只能将or条件中的每个列都加上索引)。对于多列索引,不是使用的第一部分,则不会使用索引。like查询是以%开头。如果列类型是字符串,那一定要在条件中将数据使用引号引用起来,否则不使用索引。如果mysql估计使用全表扫描要比使用索引快,则不使用索引。例如,使用<>、not in 、not exist,对于这三种情况大多数情况下认为结果集很大,MySQL就有可能不使用索引。 81题 主键不能重复,不能为空,唯一键不能重复,可以为空。建立主键的目的是让外键来引用。一个表最多只有一个主键,但可以有很多唯一键。 80题 空值('')是不占用空间的,判断空字符用=''或者<>''来进行处理。NULL值是未知的,且占用空间,不走索引;判断 NULL 用 IS NULL 或者 is not null ,SQL 语句函数中可以使用 ifnull ()函数来进行处理。无法比较 NULL 和 0;它们是不等价的。无法使用比较运算符来测试 NULL 值,比如 =, <, 或者 <>。NULL 值可以使用 <=> 符号进行比较,该符号与等号作用相似,但对NULL有意义。进行 count ()统计某列的记录数的时候,如果采用的 NULL 值,会被系统自动忽略掉,但是空值是统计到其中。 79题 HEAP表是访问数据速度最快的MySQL表,他使用保存在内存中的散列索引。一旦服务器重启,所有heap表数据丢失。BLOB或TEXT字段是不允许的。只能使用比较运算符=,<,>,=>,= <。HEAP表不支持AUTO_INCREMENT。索引不可为NULL。 78题 如果想输入字符为十六进制数字,可以输入带有单引号的十六进制数字和前缀(X),或者只用(Ox)前缀输入十六进制数字。如果表达式上下文是字符串,则十六进制数字串将自动转换为字符串。 77题 Mysql服务器通过权限表来控制用户对数据库的访问,权限表存放在mysql数据库里,由mysql_install_db脚本初始化。这些权限表分别user,db,table_priv,columns_priv和host。 76题 在缺省模式下,MYSQL是autocommit模式的,所有的数据库更新操作都会即时提交,所以在缺省情况下,mysql是不支持事务的。但是如果你的MYSQL表类型是使用InnoDB Tables 或 BDB tables的话,你的MYSQL就可以使用事务处理,使用SET AUTOCOMMIT=0就可以使MYSQL允许在非autocommit模式,在非autocommit模式下,你必须使用COMMIT来提交你的更改,或者用ROLLBACK来回滚你的更改。 75题 它会停止递增,任何进一步的插入都将产生错误,因为密钥已被使用。 74题 创建索引的时候尽量使用唯一性大的列来创建索引,由于使用b+tree做为索引,以innodb为例,一个树节点的大小由“innodb_page_size”,为了减少树的高度,同时让一个节点能存放更多的值,索引列尽量在整数类型上创建,如果必须使用字符类型,也应该使用长度较少的字符类型。 73题 当MySQL单表记录数过大时,数据库的CRUD性能会明显下降,一些常见的优化措施如下: 限定数据的范围: 务必禁止不带任何限制数据范围条件的查询语句。比如:我们当用户在查询订单历史的时候,我们可以控制在一个月的范围内。读/写分离: 经典的数据库拆分方案,主库负责写,从库负责读。垂直分区: 根据数据库里面数据表的相关性进行拆分。简单来说垂直拆分是指数据表列的拆分,把一张列比较多的表拆分为多张表。水平分区: 保持数据表结构不变,通过某种策略存储数据分片。这样每一片数据分散到不同的表或者库中,达到了分布式的目的。水平拆分可以支撑非常大的数据量。 72题 乐观锁失败后会抛出ObjectOptimisticLockingFailureException,那么我们就针对这块考虑一下重试,自定义一个注解,用于做切面。针对注解进行切面,设置最大重试次数n,然后超过n次后就不再重试。 71题 一致性非锁定读讲的是一条记录被加了X锁其他事务仍然可以读而不被阻塞,是通过innodb的行多版本实现的,行多版本并不是实际存储多个版本记录而是通过undo实现(undo日志用来记录数据修改前的版本,回滚时会用到,用来保证事务的原子性)。一致性锁定读讲的是我可以通过SELECT语句显式地给一条记录加X锁从而保证特定应用场景下的数据一致性。 70题 数据库引擎:尤其是mysql数据库只有是InnoDB引擎的时候事物才能生效。 show engines 查看数据库默认引擎;SHOW TABLE STATUS from 数据库名字 where Name='表名' 如下;SHOW TABLE STATUS from rrz where Name='rrz_cust';修改表的引擎alter table table_name engine=innodb。 69题 如果是等值查询,那么哈希索引明显有绝对优势,因为只需要经过一次算法即可找到相应的键值;当然了,这个前提是,键值都是唯一的。如果键值不是唯一的,就需要先找到该键所在位置,然后再根据链表往后扫描,直到找到相应的数据;如果是范围查询检索,这时候哈希索引就毫无用武之地了,因为原先是有序的键值,经过哈希算法后,有可能变成不连续的了,就没办法再利用索引完成范围查询检索;同理,哈希索引也没办法利用索引完成排序,以及like ‘xxx%’ 这样的部分模糊查询(这种部分模糊查询,其实本质上也是范围查询);哈希索引也不支持多列联合索引的最左匹配规则;B+树索引的关键字检索效率比较平均,不像B树那样波动幅度大,在有大量重复键值情况下,哈希索引的效率也是极低的,因为存在所谓的哈希碰撞问题。 68题 decimal精度比float高,数据处理比float简单,一般优先考虑,但float存储的数据范围大,所以范围大的数据就只能用它了,但要注意一些处理细节,因为不精确可能会与自己想的不一致,也常有关于float 出错的问题。 67题 datetime、timestamp精确度都是秒,datetime与时区无关,存储的范围广(1001-9999),timestamp与时区有关,存储的范围小(1970-2038)。 66题 Char使用固定长度的空间进行存储,char(4)存储4个字符,根据编码方式的不同占用不同的字节,gbk编码方式,不论是中文还是英文,每个字符占用2个字节的空间,utf8编码方式,每个字符占用3个字节的空间。Varchar保存可变长度的字符串,使用额外的一个或两个字节存储字符串长度,varchar(10),除了需要存储10个字符,还需要1个字节存储长度信息(10),超过255的长度需要2个字节来存储。char和varchar后面如果有空格,char会自动去掉空格后存储,varchar虽然不会去掉空格,但在进行字符串比较时,会去掉空格进行比较。Varbinary保存变长的字符串,后面不会补\0。 65题 首先分析语句,看看是否load了额外的数据,可能是查询了多余的行并且抛弃掉了,可能是加载了许多结果中并不需要的列,对语句进行分析以及重写。分析语句的执行计划,然后获得其使用索引的情况,之后修改语句或者修改索引,使得语句可以尽可能的命中索引。如果对语句的优化已经无法进行,可以考虑表中的数据量是否太大,如果是的话可以进行横向或者纵向的分表。 64题 建立索引的时候一般要考虑到字段的使用频率,经常作为条件进行查询的字段比较适合。如果需要建立联合索引的话,还需要考虑联合索引中的顺序。此外也要考虑其他方面,比如防止过多的所有对表造成太大的压力。这些都和实际的表结构以及查询方式有关。 63题 存储过程是一些预编译的SQL语句。1、更加直白的理解:存储过程可以说是一个记录集,它是由一些T-SQL语句组成的代码块,这些T-SQL语句代码像一个方法一样实现一些功能(对单表或多表的增删改查),然后再给这个代码块取一个名字,在用到这个功能的时候调用他就行了。2、存储过程是一个预编译的代码块,执行效率比较高,一个存储过程替代大量T_SQL语句 ,可以降低网络通信量,提高通信速率,可以一定程度上确保数据安全。 62题 密码散列、盐、用户身份证号等固定长度的字符串应该使用char而不是varchar来存储,这样可以节省空间且提高检索效率。 61题 推荐使用自增ID,不要使用UUID。因为在InnoDB存储引擎中,主键索引是作为聚簇索引存在的,也就是说,主键索引的B+树叶子节点上存储了主键索引以及全部的数据(按照顺序),如果主键索引是自增ID,那么只需要不断向后排列即可,如果是UUID,由于到来的ID与原来的大小不确定,会造成非常多的数据插入,数据移动,然后导致产生很多的内存碎片,进而造成插入性能的下降。总之,在数据量大一些的情况下,用自增主键性能会好一些。 60题 char是一个定长字段,假如申请了char(10)的空间,那么无论实际存储多少内容。该字段都占用10个字符,而varchar是变长的,也就是说申请的只是最大长度,占用的空间为实际字符长度+1,最后一个字符存储使用了多长的空间。在检索效率上来讲,char > varchar,因此在使用中,如果确定某个字段的值的长度,可以使用char,否则应该尽量使用varchar。例如存储用户MD5加密后的密码,则应该使用char。 59题 一. read uncommitted(读取未提交数据) 即便是事务没有commit,但是我们仍然能读到未提交的数据,这是所有隔离级别中最低的一种。 二. read committed(可以读取其他事务提交的数据)---大多数数据库默认的隔离级别 当前会话只能读取到其他事务提交的数据,未提交的数据读不到。 三. repeatable read(可重读)---MySQL默认的隔离级别 当前会话可以重复读,就是每次读取的结果集都相同,而不管其他事务有没有提交。 四. serializable(串行化) 其他会话对该表的写操作将被挂起。可以看到,这是隔离级别中最严格的,但是这样做势必对性能造成影响。所以在实际的选用上,我们要根据当前具体的情况选用合适的。 58题 B+树的高度一般为2-4层,所以查找记录时最多只需要2-4次IO,相对二叉平衡树已经大大降低了。范围查找时,能通过叶子节点的指针获取数据。例如查找大于等于3的数据,当在叶子节点中查到3时,通过3的尾指针便能获取所有数据,而不需要再像二叉树一样再获取到3的父节点。 57题 因为事务在修改页时,要先记 undo,在记 undo 之前要记 undo 的 redo, 然后修改数据页,再记数据页修改的 redo。 Redo(里面包括 undo 的修改) 一定要比数据页先持久化到磁盘。 当事务需要回滚时,因为有 undo,可以把数据页回滚到前镜像的状态,崩溃恢复时,如果 redo log 中事务没有对应的 commit 记录,那么需要用 undo把该事务的修改回滚到事务开始之前。 如果有 commit 记录,就用 redo 前滚到该事务完成时并提交掉。 56题 redo log是物理日志,记录的是"在某个数据页上做了什么修改"。 binlog是逻辑日志,记录的是这个语句的原始逻辑,比如"给ID=2这一行的c字段加1"。 redo log是InnoDB引擎特有的;binlog是MySQL的Server层实现的,所有引擎都可以使用。 redo log是循环写的,空间固定会用完:binlog 是可以追加写入的。"追加写"是指binlog文件写到一定大小后会切换到下一个,并不会覆盖以前的日志。 最开始 MySQL 里并没有 InnoDB 引擎,MySQL 自带的引擎是 MyISAM,但是 MyISAM 没有 crash-safe 的能力,binlog日志只能用于归档。而InnoDB 是另一个公司以插件形式引入 MySQL 的,既然只依靠 binlog 是没有 crash-safe 能力的,所以 InnoDB 使用另外一套日志系统,也就是 redo log 来实现 crash-safe 能力。 55题 重做日志(redo log)      作用:确保事务的持久性,防止在发生故障,脏页未写入磁盘。重启数据库会进行redo log执行重做,达到事务一致性。 回滚日志(undo log)  作用:保证数据的原子性,保存了事务发生之前的数据的一个版本,可以用于回滚,同时可以提供多版本并发控制下的读(MVCC),也即非锁定读。 二进 制日志(binlog)    作用:用于主从复制,实现主从同步;用于数据库的基于时间点的还原。 错误日志(errorlog) 作用:Mysql本身启动,停止,运行期间发生的错误信息。 慢查询日志(slow query log)  作用:记录执行时间过长的sql,时间阈值可以配置,只记录执行成功。 一般查询日志(general log)    作用:记录数据库的操作明细,默认关闭,开启后会降低数据库性能 。 中继日志(relay log) 作用:用于数据库主从同步,将主库发来的bin log保存在本地,然后从库进行回放。 54题 MySQL有三种锁的级别:页级、表级、行级。 表级锁:开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低。 行级锁:开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。 页面锁:开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间,并发度一般。 死锁: 是指两个或两个以上的进程在执行过程中。因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去。 死锁的关键在于:两个(或以上)的Session加锁的顺序不一致。 那么对应的解决死锁问题的关键就是:让不同的session加锁有次序。死锁的解决办法:1.查出的线程杀死。2.设置锁的超时时间。3.指定获取锁的顺序。 53题 当多个用户并发地存取数据时,在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据,破坏数据库的一致性(脏读,不可重复读,幻读等),可能产生死锁。 乐观锁:乐观锁不是数据库自带的,需要我们自己去实现。 悲观锁:在进行每次操作时都要通过获取锁才能进行对相同数据的操作。 共享锁:加了共享锁的数据对象可以被其他事务读取,但不能修改。 排他锁:当数据对象被加上排它锁时,一个事务必须得到锁才能对该数据对象进行访问,一直到事务结束锁才被释放。 行锁:就是给某一条记录加上锁。 52题 Mysql是关系型数据库,MongoDB是非关系型数据库,数据存储结构的不同。 51题 关系型数据库优点:1.保持数据的一致性(事务处理)。 2.由于以标准化为前提,数据更新的开销很小。 3. 可以进行Join等复杂查询。 缺点:1、为了维护一致性所付出的巨大代价就是其读写性能比较差。 2、固定的表结构。 3、高并发读写需求。 4、海量数据的高效率读写。 非关系型数据库优点:1、无需经过sql层的解析,读写性能很高。 2、基于键值对,数据没有耦合性,容易扩展。 3、存储数据的格式:nosql的存储格式是key,value形式、文档形式、图片形式等等,文档形式、图片形式等等,而关系型数据库则只支持基础类型。 缺点:1、不提供sql支持,学习和使用成本较高。 2、无事务处理,附加功能bi和报表等支持也不好。 redis与mongoDB的区别: 性能:TPS方面redis要大于mongodb。 可操作性:mongodb支持丰富的数据表达,索引,redis较少的网络IO次数。 可用性:MongoDB优于Redis。 一致性:redis事务支持比较弱,mongoDB不支持事务。 数据分析:mongoDB内置了数据分析的功能(mapreduce)。 应用场景:redis数据量较小的更性能操作和运算上,MongoDB主要解决海量数据的访问效率问题。 50题 如果Redis被当做缓存使用,使用一致性哈希实现动态扩容缩容。如果Redis被当做一个持久化存储使用,必须使用固定的keys-to-nodes映射关系,节点的数量一旦确定不能变化。否则的话(即Redis节点需要动态变化的情况),必须使用可以在运行时进行数据再平衡的一套系统,而当前只有Redis集群可以做到这样。 49题 分区可以让Redis管理更大的内存,Redis将可以使用所有机器的内存。如果没有分区,你最多只能使用一台机器的内存。分区使Redis的计算能力通过简单地增加计算机得到成倍提升,Redis的网络带宽也会随着计算机和网卡的增加而成倍增长。 48题 除了缓存服务器自带的缓存失效策略之外(Redis默认的有6种策略可供选择),我们还可以根据具体的业务需求进行自定义的缓存淘汰,常见的策略有两种: 1.定时去清理过期的缓存; 2.当有用户请求过来时,再判断这个请求所用到的缓存是否过期,过期的话就去底层系统得到新数据并更新缓存。 两者各有优劣,第一种的缺点是维护大量缓存的key是比较麻烦的,第二种的缺点就是每次用户请求过来都要判断缓存失效,逻辑相对比较复杂!具体用哪种方案,可以根据应用场景来权衡。 47题 Redis提供了两种方式来作消息队列: 一个是使用生产者消费模式模式:会让一个或者多个客户端监听消息队列,一旦消息到达,消费者马上消费,谁先抢到算谁的,如果队列里没有消息,则消费者继续监听 。另一个就是发布订阅者模式:也是一个或多个客户端订阅消息频道,只要发布者发布消息,所有订阅者都能收到消息,订阅者都是平等的。 46题 Redis的数据结构列表(list)可以实现延时队列,可以通过队列和栈来实现。blpop/brpop来替换lpop/rpop,blpop/brpop阻塞读在队列没有数据的时候,会立即进入休眠状态,一旦数据到来,则立刻醒过来。Redis的有序集合(zset)可以用于实现延时队列,消息作为value,时间作为score。Zrem 命令用于移除有序集中的一个或多个成员,不存在的成员将被忽略。当 key 存在但不是有序集类型时,返回一个错误。 45题 1.热点数据缓存:因为Redis 访问速度块、支持的数据类型比较丰富。 2.限时业务:expire 命令设置 key 的生存时间,到时间后自动删除 key。 3.计数器:incrby 命令可以实现原子性的递增。 4.排行榜:借助 SortedSet 进行热点数据的排序。 5.分布式锁:利用 Redis 的 setnx 命令进行。 6.队列机制:有 list push 和 list pop 这样的命令。 44题 一致哈希 是一种特殊的哈希算法。在使用一致哈希算法后,哈希表槽位数(大小)的改变平均只需要对 K/n 个关键字重新映射,其中K是关键字的数量, n是槽位数量。然而在传统的哈希表中,添加或删除一个槽位的几乎需要对所有关键字进行重新映射。 43题 RDB的优点:适合做冷备份;读写服务影响小,reids可以保持高性能;重启和恢复redis进程,更加快速。RDB的缺点:宕机会丢失最近5分钟的数据;文件特别大时可能会暂停数毫秒,或者甚至数秒。 AOF的优点:每个一秒执行fsync操作,最多丢失1秒钟的数据;以append-only模式写入,没有任何磁盘寻址的开销;文件过大时,不会影响客户端读写;适合做灾难性的误删除的紧急恢复。AOF的缺点:AOF日志文件比RDB数据快照文件更大,支持写QPS比RDB支持的写QPS低;比RDB脆弱,容易有bug。 42题 对于Redis而言,命令的原子性指的是:一个操作的不可以再分,操作要么执行,要么不执行。Redis的操作之所以是原子性的,是因为Redis是单线程的。而在程序中执行多个Redis命令并非是原子性的,这也和普通数据库的表现是一样的,可以用incr或者使用Redis的事务,或者使用Redis+Lua的方式实现。对Redis来说,执行get、set以及eval等API,都是一个一个的任务,这些任务都会由Redis的线程去负责执行,任务要么执行成功,要么执行失败,这就是Redis的命令是原子性的原因。 41题 (1)twemproxy,使用方式简单(相对redis只需修改连接端口),对旧项目扩展的首选。(2)codis,目前用的最多的集群方案,基本和twemproxy一致的效果,但它支持在节点数改变情况下,旧节点数据可恢复到新hash节点。(3)redis cluster3.0自带的集群,特点在于他的分布式算法不是一致性hash,而是hash槽的概念,以及自身支持节点设置从节点。(4)在业务代码层实现,起几个毫无关联的redis实例,在代码层,对key进行hash计算,然后去对应的redis实例操作数据。这种方式对hash层代码要求比较高,考虑部分包括,节点失效后的代替算法方案,数据震荡后的自动脚本恢复,实例的监控,等等。 40题 (1) Master最好不要做任何持久化工作,如RDB内存快照和AOF日志文件 (2) 如果数据比较重要,某个Slave开启AOF备份数据,策略设置为每秒同步一次 (3) 为了主从复制的速度和连接的稳定性,Master和Slave最好在同一个局域网内 (4) 尽量避免在压力很大的主库上增加从库 (5) 主从复制不要用图状结构,用单向链表结构更为稳定,即:Master <- Slave1 <- Slave2 <- Slave3...这样的结构方便解决单点故障问题,实现Slave对Master的替换。如果Master挂了,可以立刻启用Slave1做Master,其他不变。 39题 比如订单管理,热数据:3个月内的订单数据,查询实时性较高;温数据:3个月 ~ 12个月前的订单数据,查询频率不高;冷数据:1年前的订单数据,几乎不会查询,只有偶尔的查询需求。热数据使用mysql进行存储,需要分库分表;温数据可以存储在ES中,利用搜索引擎的特性基本上也可以做到比较快的查询;冷数据可以存放到Hive中。从存储形式来说,一般情况冷数据存储在磁带、光盘,热数据一般存放在SSD中,存取速度快,而温数据可以存放在7200转的硬盘。 38题 当访问量剧增、服务出现问题(如响应时间慢或不响应)或非核心服务影响到核心流程的性能时,仍然需要保证服务还是可用的,即使是有损服务。系统可以根据一些关键数据进行自动降级,也可以配置开关实现人工降级。降级的最终目的是保证核心服务可用,即使是有损的。而且有些服务是无法降级的(如加入购物车、结算)。 37题 分层架构设计,有一条准则:站点层、服务层要做到无数据无状态,这样才能任意的加节点水平扩展,数据和状态尽量存储到后端的数据存储服务,例如数据库服务或者缓存服务。显然进程内缓存违背了这一原则。 36题 更新数据的时候,根据数据的唯一标识,将操作路由之后,发送到一个 jvm 内部队列中。读取数据的时候,如果发现数据不在缓存中,那么将重新读取数据+更新缓存的操作,根据唯一标识路由之后,也发送同一个 jvm 内部队列中。一个队列对应一个工作线程,每个工作线程串行拿到对应的操作,然后一条一条的执行。 35题 redis分布式锁加锁过程:通过setnx向特定的key写入一个随机值,并同时设置失效时间,写值成功既加锁成功;redis分布式锁解锁过程:匹配随机值,删除redis上的特点key数据,要保证获取数据、判断一致以及删除数据三个操作是原子的,为保证原子性一般使用lua脚本实现;在此基础上进一步优化的话,考虑使用心跳检测对锁的有效期进行续期,同时基于redis的发布订阅优雅的实现阻塞式加锁。 34题 volatile-lru:当内存不足以容纳写入数据时,从已设置过期时间的数据集中挑选最近最少使用的数据淘汰。 volatile-ttl:当内存不足以容纳写入数据时,从已设置过期时间的数据集中挑选将要过期的数据淘汰。 volatile-random:当内存不足以容纳写入数据时,从已设置过期时间的数据集中任意选择数据淘汰。 allkeys-lru:当内存不足以容纳写入数据时,从数据集中挑选最近最少使用的数据淘汰。 allkeys-random:当内存不足以容纳写入数据时,从数据集中任意选择数据淘汰。 noeviction:禁止驱逐数据,当内存使用达到阈值的时候,所有引起申请内存的命令会报错。 33题 定时过期:每个设置过期时间的key都需要创建一个定时器,到过期时间就会立即清除。该策略可以立即清除过期的数据,对内存很友好;但是会占用大量的CPU资源去处理过期的数据,从而影响缓存的响应时间和吞吐量。 惰性过期:只有当访问一个key时,才会判断该key是否已过期,过期则清除。该策略可以最大化地节省CPU资源,却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问,从而不会被清除,占用大量内存。 定期过期:每隔一定的时间,会扫描一定数量的数据库的expires字典中一定数量的key,并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时,可以在不同情况下使得CPU和内存资源达到最优的平衡效果。 32题 缓存击穿,一个存在的key,在缓存过期的一刻,同时有大量的请求,这些请求都会击穿到DB,造成瞬时DB请求量大、压力骤增。如何避免:在访问key之前,采用SETNX(set if not exists)来设置另一个短期key来锁住当前key的访问,访问结束再删除该短期key。 31题 缓存雪崩,是指在某一个时间段,缓存集中过期失效。大量的key设置了相同的过期时间,导致在缓存在同一时刻全部失效,造成瞬时DB请求量大、压力骤增,引起雪崩。而缓存服务器某个节点宕机或断网,对数据库服务器造成的压力是不可预知的,很有可能瞬间就把数据库压垮。如何避免:1.redis高可用,搭建redis集群。2.限流降级,在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。3.数据预热,在即将发生大并发访问前手动触发加载缓存不同的key,设置不同的过期时间。 30题 缓存穿透,是指查询一个数据库一定不存在的数据。正常的使用缓存流程大致是,数据查询先进行缓存查询,如果key不存在或者key已经过期,再对数据库进行查询,并把查询到的对象,放进缓存。如果数据库查询对象为空,则不放进缓存。一些恶意的请求会故意查询不存在的 key,请求量很大,对数据库造成压力,甚至压垮数据库。 如何避免:1:对查询结果为空的情况也进行缓存,缓存时间设置短一点,或者该 key 对应的数据 insert 了之后清理缓存。2:对一定不存在的 key 进行过滤。可以把所有的可能存在的 key 放到一个大的 Bitmap 中,查询时通过该 bitmap 过滤。 29题 1.memcached 所有的值均是简单的字符串,redis 作为其替代者,支持更为丰富的数据类型。 2.redis 的速度比 memcached 快很多。 3.redis 可以持久化其数据。 4.Redis支持数据的备份,即master-slave模式的数据备份。 5.Redis采用VM机制。 6.value大小:redis最大可以达到1GB,而memcache只有1MB。 28题 Spring Boot 推荐使用 Java 配置而非 XML 配置,但是 Spring Boot 中也可以使用 XML 配置,通过spring提供的@ImportResource来加载xml配置。例如:@ImportResource({"classpath:some-context.xml","classpath:another-context.xml"}) 27题 Spring像一个大家族,有众多衍生产品例如Spring Boot,Spring Security等等,但他们的基础都是Spring的IOC和AOP,IOC提供了依赖注入的容器,而AOP解决了面向切面的编程,然后在此两者的基础上实现了其他衍生产品的高级功能。Spring MVC是基于Servlet的一个MVC框架,主要解决WEB开发的问题,因为 Spring的配置非常复杂,各种xml,properties处理起来比较繁琐。Spring Boot遵循约定优于配置,极大降低了Spring使用门槛,又有着Spring原本灵活强大的功能。总结:Spring MVC和Spring Boot都属于Spring,Spring MVC是基于Spring的一个MVC框架,而Spring Boot是基于Spring的一套快速开发整合包。 26题 YAML 是 "YAML Ain't a Markup Language"(YAML 不是一种标记语言)的递归缩写。YAML 的配置文件后缀为 .yml,是一种人类可读的数据序列化语言,可以简单表达清单、散列表,标量等数据形态。它通常用于配置文件,与属性文件相比,YAML文件就更加结构化,而且更少混淆。可以看出YAML具有分层配置数据。 25题 Spring Boot有3种热部署方式: 1.使用springloaded配置pom.xml文件,使用mvn spring-boot:run启动。 2.使用springloaded本地加载启动,配置jvm参数-javaagent:<jar包地址> -noverify。 3.使用devtools工具包,操作简单,但是每次需要重新部署。 用

游客ih62co2qqq5ww 2020-03-27 23:56:48 0 浏览量 回答数 0

问题

schema设计原则是什么

云栖大讲堂 2019-12-01 21:31:30 1293 浏览量 回答数 0

回答

*1、查询SQL尽量不要使用select ,而是select具体字段。 反例子: select * from employee; 正例子: select id,name from employee; 理由: 只取需要的字段,节省资源、减少网络开销。select * 进行查询时,很可能就不会使用到覆盖索引了,就会造成回表查询。 2、如果知道查询结果只有一条或者只要最大/最小一条记录,建议用limit 1 假设现在有employee员工表,要找出一个名字叫jay的人. CREATE TABLE `employee` ( `id` int(11) NOT NULL, `name` varchar(255) DEFAULT NULL, `age` int(11) DEFAULT NULL, `date` datetime DEFAULT NULL, `sex` int(1) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 反例: select id,name from employee where name='jay' 正例 select id,name from employee where name='jay' limit 1; 理由: 加上limit 1后,只要找到了对应的一条记录,就不会继续向下扫描了,效率将会大大提高。当然,如果name是唯一索引的话,是不必要加上limit 1了,因为limit的存在主要就是为了防止全表扫描,从而提高性能,如果一个语句本身可以预知不用全表扫描,有没有limit ,性能的差别并不大。 3、应尽量避免在where子句中使用or来连接条件 新建一个user表,它有一个普通索引userId,表结构如下: CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `userId` int(11) NOT NULL, `age` int(11) NOT NULL, `name` varchar(255) NOT NULL, PRIMARY KEY (`id`), KEY `idx_userId` (`userId`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 假设现在需要查询userid为1或者年龄为18岁的用户,很容易有以下sql 反例: select * from user where userid=1 or age =18 正例: //使用union all select * from user where userid=1 union all select * from user where age = 18 //或者分开两条sql写: select * from user where userid=1 select * from user where age = 18 理由: 使用or可能会使索引失效,从而全表扫描。 对于or+没有索引的age这种情况,假设它走了userId的索引,但是走到age查询条件时,它还得全表扫描,也就是需要三步过程: 全表扫描+索引扫描+合并 如果它一开始就走全表扫描,直接一遍扫描就完事。 mysql是有优化器的,处于效率与成本考虑,遇到or条件,索引可能失效,看起来也合情合理。 4、优化limit分页 我们日常做分页需求时,一般会用 limit 实现,但是当偏移量特别大的时候,查询效率就变得低下。 反例: select id,name,age from employee limit 10000,10 正例: //方案一 :返回上次查询的最大记录(偏移量) select id,name from employee where id>10000 limit 10. //方案二:order by + 索引 select id,name from employee order by id limit 10000,10 //方案三:在业务允许的情况下限制页数: 理由: 当偏移量最大的时候,查询效率就会越低,因为Mysql并非是跳过偏移量直接去取后面的数据,而是先把偏移量+要取的条数,然后再把前面偏移量这一段的数据抛弃掉再返回的。 如果使用优化方案一,返回上次最大查询记录(偏移量),这样可以跳过偏移量,效率提升不少。 方案二使用order by+索引,也是可以提高查询效率的。 方案三的话,建议跟业务讨论,有没有必要查这么后的分页啦。因为绝大多数用户都不会往后翻太多页。 5、优化你的like语句 日常开发中,如果用到模糊关键字查询,很容易想到like,但是like很可能让你的索引失效。 反例: select userId,name from user where userId like '%123'; 正例: select userId,name from user where userId like '123%'; 理由: 把%放前面,并不走索引,如下: 把% 放关键字后面,还是会走索引的。如下: 6、使用where条件限定要查询的数据,避免返回多余的行 假设业务场景是这样:查询某个用户是否是会员。曾经看过老的实现代码是这样。。。 反例: List<Long> userIds = sqlMap.queryList("select userId from user where isVip=1"); boolean isVip = userIds.contains(userId); 正例: Long userId = sqlMap.queryObject("select userId from user where userId='userId' and isVip='1' ") boolean isVip = userId!=null; 理由: 需要什么数据,就去查什么数据,避免返回不必要的数据,节省开销。 7、尽量避免在索引列上使用mysql的内置函数 业务需求:查询最近七天内登陆过的用户(假设loginTime加了索引) 反例: select userId,loginTime from loginuser where Date_ADD(loginTime,Interval 7 DAY) >=now(); 正例: explain select userId,loginTime from loginuser where loginTime >= Date_ADD(NOW(),INTERVAL - 7 DAY); 理由: 索引列上使用mysql的内置函数,索引失效 8、应尽量避免在 where 子句中对字段进行表达式操作,这将导致系统放弃使用索引而进行全表扫 反例: select * from user where age-1 =10; 正例: select * from user where age =11; 理由: 9、Inner join 、left join、right join,优先使用Inner join,如果是left join,左边表结果尽量小 Inner join 内连接,在两张表进行连接查询时,只保留两张表中完全匹配的结果集 left join 在两张表进行连接查询时,会返回左表所有的行,即使在右表中没有匹配的记录。 right join 在两张表进行连接查询时,会返回右表所有的行,即使在左表中没有匹配的记录。 都满足SQL需求的前提下,推荐优先使用Inner join(内连接),如果要使用left join,左边表数据结果尽量小,如果有条件的尽量放到左边处理。 反例: select * from tab1 t1 left join tab2 t2 on t1.size = t2.size where t1.id>2; 正例: select * from (select * from tab1 where id >2) t1 left join tab2 t2 on t1.size = t2.size; 理由: 如果inner join是等值连接,或许返回的行数比较少,所以性能相对会好一点。 同理,使用了左连接,左边表数据结果尽量小,条件尽量放到左边处理,意味着返回的行数可能比较少。 10、应尽量避免在 where 子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描。 反例: select age,name from user where age <>18; 正例: //可以考虑分开两条sql写 select age,name from user where age <18; select age,name from user where age >18; 理由: 使用!=和<>很可能会让索引失效 11、使用联合索引时,注意索引列的顺序,一般遵循最左匹配原则。 表结构:(有一个联合索引idx_userid_age,userId在前,age在后) CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `userId` int(11) NOT NULL, `age` int(11) DEFAULT NULL, `name` varchar(255) NOT NULL, PRIMARY KEY (`id`), KEY `idx_userid_age` (`userId`,`age`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8; 反例: select * from user where age = 10; 正例: //符合最左匹配原则 select * from user where userid=10 and age =10; //符合最左匹配原则 select * from user where userid =10; 理由: 当我们创建一个联合索引的时候,如(k1,k2,k3),相当于创建了(k1)、(k1,k2)和(k1,k2,k3)三个索引,这就是最左匹配原则。 联合索引不满足最左原则,索引一般会失效,但是这个还跟Mysql优化器有关的。 12、对查询进行优化,应考虑在 where 及 order by 涉及的列上建立索引,尽量避免全表扫描。 反例: select * from user where address ='深圳' order by age ; 正例: 添加索引 alter table user add index idx_address_age (address,age) 13、如果插入数据过多,考虑批量插入。 反例: for(User u :list){ INSERT into user(name,age) values(#name#,#age#) } 正例: //一次500批量插入,分批进行 insert into user(name,age) values <foreach collection="list" item="item" index="index" separator=","> (#{item.name},#{item.age}) </foreach> 理由: 批量插入性能好,更加省时间 打个比喻:假如你需要搬一万块砖到楼顶,你有一个电梯,电梯一次可以放适量的砖(最多放500),你可以选择一次运送一块砖,也可以一次运送500,你觉得哪个时间消耗大? 14、在适当的时候,使用覆盖索引。 覆盖索引能够使得你的SQL语句不需要回表,仅仅访问索引就能够得到所有需要的数据,大大提高了查询效率。 反例: // like模糊查询,不走索引了 select * from user where userid like '%123%' 正例: //id为主键,那么为普通索引,即覆盖索引登场了。 select id,name from user where userid like '%123%'; 15、慎用distinct关键字 distinct 关键字一般用来过滤重复记录,以返回不重复的记录。在查询一个字段或者很少字段的情况下使用时,给查询带来优化效果。但是在字段很多的时候使用,却会大大降低查询效率。 反例: SELECT DISTINCT * from user; 正例: select DISTINCT name from user; 理由: 带distinct的语句cpu时间和占用时间都高于不带distinct的语句。因为当查询很多字段时,如果使用distinct,数据库引擎就会对数据进行比较,过滤掉重复数据,然而这个比较,过滤的过程会占用系统资源,cpu时间。 16、删除冗余和重复索引 反例: KEY `idx_userId` (`userId`) KEY `idx_userId_age` (`userId`,`age`) 正例: //删除userId索引,因为组合索引(A,B)相当于创建了(A)和(A,B)索引 KEY `idx_userId_age` (`userId`,`age`) 理由: 重复的索引需要维护,并且优化器在优化查询的时候也需要逐个地进行考虑,这会影响性能的。 17、如果数据量较大,优化你的修改/删除语句。 避免同时修改或删除过多数据,因为会造成cpu利用率过高,从而影响别人对数据库的访问。 反例: //一次删除10万或者100万+? delete from user where id <100000; //或者采用单一循环操作,效率低,时间漫长 for(User user:list){ delete from user; } 正例: //分批进行删除,如每次500 delete user where id<500 delete product where id>=500 and id<1000; 理由: 一次性删除太多数据,可能会有lock wait timeout exceed的错误,所以建议分批操作。 18、where子句中考虑使用默认值代替null。 反例: select * from user where age is not null; 正例: //设置0为默认值 select * from user where age>0; 理由: 并不是说使用了is null 或者 is not null 就会不走索引了,这个跟mysql版本以及查询成本都有关。 如果mysql优化器发现,走索引比不走索引成本还要高,肯定会放弃索引,这些条件!=,>is null,is not null经常被认为让索引失效,其实是因为一般情况下,查询的成本高,优化器自动放弃的。 如果把null值,换成默认值,很多时候让走索引成为可能,同时,表达意思会相对清晰一点。 19、不要有超过5个以上的表连接 连表越多,编译的时间和开销也就越大。 把连接表拆开成较小的几个执行,可读性更高。 如果一定需要连接很多表才能得到数据,那么意味着糟糕的设计了。 20、exist & in的合理利用 假设表A表示某企业的员工表,表B表示部门表,查询所有部门的所有员工,很容易有以下SQL: select * from A where deptId in (select deptId from B); 这样写等价于: 先查询部门表B select deptId from B 再由部门deptId,查询A的员工 select * from A where A.deptId = B.deptId 可以抽象成这样的一个循环: List<> resultSet ; for(int i=0;i<B.length;i++) { for(int j=0;j<A.length;j++) { if(A[i].id==B[j].id) { resultSet.add(A[i]); break; } } } 显然,除了使用in,我们也可以用exists实现一样的查询功能,如下: select * from A where exists (select 1 from B where A.deptId = B.deptId); 因为exists查询的理解就是,先执行主查询,获得数据后,再放到子查询中做条件验证,根据验证结果(true或者false),来决定主查询的数据结果是否得意保留。 那么,这样写就等价于: select * from A,先从A表做循环 select * from B where A.deptId = B.deptId,再从B表做循环. 同理,可以抽象成这样一个循环: List<> resultSet ; for(int i=0;i<A.length;i++) { for(int j=0;j<B.length;j++) { if(A[i].deptId==B[j].deptId) { resultSet.add(A[i]); break; } } } 数据库最费劲的就是跟程序链接释放。假设链接了两次,每次做上百万次的数据集查询,查完就走,这样就只做了两次;相反建立了上百万次链接,申请链接释放反复重复,这样系统就受不了了。即mysql优化原则,就是小表驱动大表,小的数据集驱动大的数据集,从而让性能更优。 因此,我们要选择最外层循环小的,也就是,如果B的数据量小于A,适合使用in,如果B的数据量大于A,即适合选择exist。 21、尽量用 union all 替换 union 如果检索结果中不会有重复的记录,推荐union all 替换 union。 反例: select * from user where userid=1 union select * from user where age = 10 正例: select * from user where userid=1 union all select * from user where age = 10 理由: 如果使用union,不管检索结果有没有重复,都会尝试进行合并,然后在输出最终结果前进行排序。如果已知检索结果没有重复记录,使用union all 代替union,这样会提高效率。 22、索引不宜太多,一般5个以内。 索引并不是越多越好,索引虽然提高了查询的效率,但是也降低了插入和更新的效率。 insert或update时有可能会重建索引,所以建索引需要慎重考虑,视具体情况来定。 一个表的索引数最好不要超过5个,若太多需要考虑一些索引是否没有存在的必要。 23、尽量使用数字型字段,若只含数值信息的字段尽量不要设计为字符型 反例: king_id` varchar(20) NOT NULL COMMENT '守护者Id' 正例: `king_id` int(11) NOT NULL COMMENT '守护者Id'` 理由: 相对于数字型字段,字符型会降低查询和连接的性能,并会增加存储开销。 24、索引不适合建在有大量重复数据的字段上,如性别这类型数据库字段。 因为SQL优化器是根据表中数据量来进行查询优化的,如果索引列有大量重复数据,Mysql查询优化器推算发现不走索引的成本更低,很可能就放弃索引了。 25、尽量避免向客户端返回过多数据量。 假设业务需求是,用户请求查看自己最近一年观看过的直播数据。 反例: //一次性查询所有数据回来 select * from LivingInfo where watchId =useId and watchTime >= Date_sub(now(),Interval 1 Y) 正例: //分页查询 select * from LivingInfo where watchId =useId and watchTime>= Date_sub(now(),Interval 1 Y) limit offset,pageSize //如果是前端分页,可以先查询前两百条记录,因为一般用户应该也不会往下翻太多页, select * from LivingInfo where watchId =useId and watchTime>= Date_sub(now(),Interval 1 Y) limit 200 ; 26、当在SQL语句中连接多个表时,请使用表的别名,并把别名前缀于每一列上,这样语义更加清晰。 反例: select * from A inner join B on A.deptId = B.deptId; 正例: select memeber.name,deptment.deptName from A member inner join B deptment on member.deptId = deptment.deptId; 27、尽可能使用varchar/nvarchar 代替 char/nchar。 反例: `deptName` char(100) DEFAULT NULL COMMENT '部门名称' 正例: `deptName` varchar(100) DEFAULT NULL COMMENT '部门名称' 理由: 因为首先变长字段存储空间小,可以节省存储空间。 其次对于查询来说,在一个相对较小的字段内搜索,效率更高。 28、为了提高group by 语句的效率,可以在执行到该语句前,把不需要的记录过滤掉。 反例: select job,avg(salary) from employee group by job having job ='president' or job = 'managent' 正例: select job,avg(salary) from employee where job ='president' or job = 'managent' group by job; 29、如何字段类型是字符串,where时一定用引号括起来,否则索引失效 反例: select * from user where userid =123; 正例: select * from user where userid ='123'; 理由: 为什么第一条语句未加单引号就不走索引了呢? 这是因为不加单引号时,是字符串跟数字的比较,它们类型不匹配,MySQL会做隐式的类型转换,把它们转换为浮点数再做比较。 30、使用explain 分析你SQL的计划 日常开发写SQL的时候,尽量养成一个习惯吧。用explain分析一下你写的SQL,尤其是走不走索引这一块。 explain select * from user where userid =10086 or age =18;

剑曼红尘 2020-04-21 14:01:32 0 浏览量 回答数 0

问题

数据聚合分组:新一代系统监控的核心功能

doudou1 2019-12-01 20:55:20 8687 浏览量 回答数 3

回答

. 在编写一个类时,如果该类中的代码可能运行与多线程环境下,就要考虑同步问题了。 会同时被多个线程访问的资源,就是竞争资源,也称为竞争条件。对于多线程共享的资源我们必须进行同步,以避免一个线程的改动被另一个线程所覆盖。 synchronized 关键字有两种作用域: 1> 某个对象实例内,synchronized aMethod(){}关键字可以防止多个线程访问对象的synchronized方法(如果一个对象有多个synchronized方法,只要一个线程访问了其中的一个synchronized方法,其它线程不能同时访问这个对象中任何一个synchronized方法)。这时,不同的对象实例的synchronized方法是不相干扰的。也就是说,其它线程照样可以同时访问相同类的另一个对象实例中的synchronized方法. 2> 是某个类的范围,synchronized static aStaticMethod{}防止多个线程同时访问这个类中的synchronized static 方法。它可以对类的所有对象实例起作用。 synchronized关键字是不能继承的,也就是说,基类的方法synchronized f(){} 在继承类中并不自动是synchronized f(){},而是变成了f(){}。继承类需要你显式的指定它的某个方法为synchronized方法; Java语言的关键字,当它用来修饰一个方法或者一个代码块的时候,能够保证在同一时刻最多只有一个线程执行该段代码。      一、当两个并发线程访问同一个对象object中的这个synchronized(this)同步代码块时,一个时间内只能有一个线程得到执行。另一个线程必须等待当前线程执行完这个代码块以后才能执行该代码块。      二、然而,当一个线程访问object的一个synchronized(this)同步代码块时,另一个线程仍然可以访问该object中的非synchronized(this)同步代码块。      三、尤其关键的是,当一个线程访问object的一个synchronized(this)同步代码块时,其他线程对object中所有其它synchronized(this)同步代码块的访问将被阻塞。      四、第三个例子同样适用其它同步代码块。也就是说,当一个线程访问object的一个synchronized(this)同步代码块时,它就获得了这个object的对象锁。结果,其它线程对该object对象所有同步代码部   分的访问都被暂时阻塞。      五、以上规则对其它对象锁同样适用. 2. synchronized 关键字,它包括两种用法:synchronized 方法和 synchronized 块。   synchronized 方法:通过在方法声明中加入 synchronized关键字来声明 synchronized 方法。如:   synchronized void accessVal(int newVal);   synchronized 方法控制对类成员变量的访问:每个类实例对应一把锁,每个 synchronized 方法都必须获得调用该方法的类实例的锁方能 执行,否则所属线程阻塞,方法一旦执行,就独占该锁,直到从该方法返回时才将锁释放,此后被阻塞的线程方能获得该锁,重新进入可执行 状态。这种机制确保了同一时刻对于每一个类实例,其所有声明为 synchronized 的成员函数中至多只有一个处于可执行状态(因为至多只有 一个能够获得该类实例对应的锁),从而有效避免了类成员变量的访问冲突(只要所有可能访问类成员变量的方法均被声明为 synchronized) 。  在 Java 中,不光是类实例,每一个类也对应一把锁,这样我们也可将类的静态成员函数声明为 synchronized ,以控制其对类的静态成 员变量的访问。  synchronized 方法的缺陷:若将一个大的方法声明为synchronized 将会大大影响效率,典型地,若将线程类的方法 run() 声明为 synchronized ,由于在线程的整个生命期内它一直在运行,因此将导致它对本类任何 synchronized 方法的调用都永远不会成功。当然我们可 以通过将访问类成员变量的代码放到专门的方法中,将其声明为 synchronized ,并在主方法中调用来解决这一问题,但是 Java 为我们提供 了更好的解决办法,那就是 synchronized 块。   synchronized 块:通过 synchronized关键字来声明synchronized 块。语法如下:  synchronized(syncObject) {   //允许访问控制的代码  }  synchronized 块是这样一个代码块,其中的代码必须获得对象 syncObject (如前所述,可以是类实例或类)的锁方能执行,具体机 制同前所述。由于可以针对任意代码块,且可任意指定上锁的对象,故灵活性较高。  对synchronized(this)的一些理解 一、当两个并发线程访问同一个对象object中的这个synchronized(this)同步代码块时,一个时间内只能有一个线程得到执行。另一个线 程必须等待当前线程执行完这个代码块以后才能执行该代码块。  二、然而,当一个线程访问object的一个synchronized(this)同步代码块时,另一个线程仍然可以访问该object中的非synchronized (this)同步代码块。  三、尤其关键的是,当一个线程访问object的一个synchronized(this)同步代码块时,其他线程对object中所有其它synchronized(this) 同步代码块的访问将被阻塞。  四、第三个例子同样适用其它同步代码块。也就是说,当一个线程访问object的一个synchronized(this)同步代码块时,它就获得了这个 object的对象锁。结果,其它线程对该object对象所有同步代码部分的访问都被暂时阻塞。  五、以上规则对其它对象锁同样适用 3.打个比方:一个object就像一个大房子,大门永远打开。房子里有 很多房间(也就是方法)。 这些房间有上锁的(synchronized方法), 和不上锁之分(普通方法)。房门口放着一把钥匙(key),这把钥匙可以打开所有上锁的房间。 另外我把所有想调用该对象方法的线程比喻成想进入这房子某个 房间的人。所有的东西就这么多了,下面我们看看这些东西之间如何作用的。 在此我们先来明确一下我们的前提条件。该对象至少有一个synchronized方法,否则这个key还有啥意义。当然也就不会有我们的这个主题了。 一个人想进入某间上了锁的房间,他来到房子门口,看见钥匙在那儿(说明暂时还没有其他人要使用上锁的 房间)。于是他走上去拿到了钥匙 ,并且按照自己 的计划使用那些房间。注意一点,他每次使用完一次上锁的房间后会马上把钥匙还回去。即使他要连续使用两间上锁的房间, 中间他也要把钥匙还回去,再取回来。 因此,普通情况下钥匙的使用原则是:“随用随借,用完即还。” 这时其他人可以不受限制的使用那些不上锁的房间,一个人用一间可以,两个人用一间也可以,没限制。但是如果当某个人想要进入上锁的房 间,他就要跑到大门口去看看了。有钥匙当然拿了就走,没有的话,就只能等了。 要是很多人在等这把钥匙,等钥匙还回来以后,谁会优先得到钥匙?Not guaranteed。象前面例子里那个想连续使用两个上锁房间的家伙,他 中间还钥匙的时候如果还有其他人在等钥匙,那么没有任何保证这家伙能再次拿到。 (JAVA规范在很多地方都明确说明不保证,象 Thread.sleep()休息后多久会返回运行,相同优先权的线程那个首先被执行,当要访问对象的锁被 释放后处于等待池的多个线程哪个会优先得 到,等等。我想最终的决定权是在JVM,之所以不保证,就是因为JVM在做出上述决定的时候,绝不是简简单单根据 一个条件来做出判断,而是 根据很多条。而由于判断条件太多,如果说出来可能会影响JAVA的推广,也可能是因为知识产权保护的原因吧。SUN给了个不保证 就混过去了 。无可厚非。但我相信这些不确定,并非完全不确定。因为计算机这东西本身就是按指令运行的。即使看起来很随机的现象,其实都是有规律 可寻。学过 计算机的都知道,计算机里随机数的学名是伪随机数,是人运用一定的方法写出来的,看上去随机罢了。另外,或许是因为要想弄 的确定太费事,也没多大意义,所 以不确定就不确定了吧。) 再来看看同步代码块。和同步方法有小小的不同。 1.从尺寸上讲,同步代码块比同步方法小。你可以把同步代码块看成是没上锁房间里的一块用带锁的屏风隔开的空间。 2.同步代码块还可以人为的指定获得某个其它对象的key。就像是指定用哪一把钥匙才能开这个屏风的锁,你可以用本房的钥匙;你也可以指定 用另一个房子的钥匙才能开,这样的话,你要跑到另一栋房子那儿把那个钥匙拿来,并用那个房子的钥匙来打开这个房子的带锁的屏风。          记住你获得的那另一栋房子的钥匙,并不影响其他人进入那栋房子没有锁的房间。          为什么要使用同步代码块呢?我想应该是这样的:首先对程序来讲同步的部分很影响运行效率,而一个方法通常是先创建一些局部变 量,再对这些变量做一些 操作,如运算,显示等等;而同步所覆盖的代码越多,对效率的影响就越严重。因此我们通常尽量缩小其影响范围。 如何做?同步代码块。我们只把一个方法中该同 步的地方同步,比如运算。          另外,同步代码块可以指定钥匙这一特点有个额外的好处,是可以在一定时期内霸占某个对象的key。还记得前面说过普通情况下钥 匙的使用原则吗。现在不是普通情况了。你所取得的那把钥匙不是永远不还,而是在退出同步代码块时才还。           还用前面那个想连续用两个上锁房间的家伙打比方。怎样才能在用完一间以后,继续使用另一间呢。用同步代码块吧。先创建另外 一个线程,做一个同步代码 块,把那个代码块的锁指向这个房子的钥匙。然后启动那个线程。只要你能在进入那个代码块时抓到这房子的钥匙 ,你就可以一直保留到退出那个代码块。也就是说 你甚至可以对本房内所有上锁的房间遍历,甚至再sleep(10601000),而房门口却还有 1000个线程在等这把钥匙呢。很过瘾吧。           在此对sleep()方法和钥匙的关联性讲一下。一个线程在拿到key后,且没有完成同步的内容时,如果被强制sleep()了,那key还一 直在 它那儿。直到它再次运行,做完所有同步内容,才会归还key。记住,那家伙只是干活干累了,去休息一下,他并没干完他要干的事。为 了避免别人进入那个房间 把里面搞的一团糟,即使在睡觉的时候他也要把那唯一的钥匙戴在身上。           最后,也许有人会问,为什么要一把钥匙通开,而不是一个钥匙一个门呢?我想这纯粹是因为复杂性问题。一个钥匙一个门当然更 安全,但是会牵扯好多问题。钥匙 的产生,保管,获得,归还等等。其复杂性有可能随同步方法的增加呈几何级数增加,严重影响效率。这也 算是一个权衡的问题吧。为了增加一点点安全性,导致效 率大大降低,是多么不可取啊。 synchronized的一个简单例子 public class TextThread { public static void main(String[] args) {    TxtThread tt = new TxtThread();    new Thread(tt).start();    new Thread(tt).start();    new Thread(tt).start();    new Thread(tt).start(); } } class TxtThread implements Runnable { int num = 100; String str = new String(); public void run() {    synchronized (str) {     while (num > 0) {      try {       Thread.sleep(1);      } catch (Exception e) {       e.getMessage();      }      System.out.println(Thread.currentThread().getName()        + "this is " + num--);     }    } } } 上面的例子中为了制造一个时间差,也就是出错的机会,使用了Thread.sleep(10) Java对多线程的支持与同步机制深受大家的喜爱,似乎看起来使用了synchronized关键字就可以轻松地解决多线程共享数据同步问题。到底如 何?――还得对synchronized关键字的作用进行深入了解才可定论。 总的说来,synchronized关键字可以作为函数的修饰符,也可作为函数内的语句,也就是平时说的同步方法和同步语句块。如果再细的分类, synchronized可作用于instance变量、object reference(对象引用)、static函数和class literals(类名称字面常量)身上。 在进一步阐述之前,我们需要明确几点: A.无论synchronized关键字加在方法上还是对象上,它取得的锁都是对象,而不是把一段代码或函数当作锁――而且同步方法很可能还会被其 他线程的对象访问。 B.每个对象只有一个锁(lock)与之相关联。 C.实现同步是要很大的系统开销作为代价的,甚至可能造成死锁,所以尽量避免无谓的同步控制。 接着来讨论synchronized用到不同地方对代码产生的影响: 假设P1、P2是同一个类的不同对象,这个类中定义了以下几种情况的同步块或同步方法,P1、P2就都可以调用它们。 1. 把synchronized当作函数修饰符时,示例代码如下: Public synchronized void methodAAA() { //…. } 这也就是同步方法,那这时synchronized锁定的是哪个对象呢?它锁定的是调用这个同步方法对象。也就是说,当一个对象P1在不同的线程中 执行这个同步方法时,它们之间会形成互斥,达到同步的效果。但是这个对象所属的Class所产生的另一对象P2却可以任意调用这个被加了 synchronized关键字的方法。 上边的示例代码等同于如下代码: public void methodAAA() { synchronized (this)      // (1) {        //….. } } (1)处的this指的是什么呢?它指的就是调用这个方法的对象,如P1。可见同步方法实质是将synchronized作用于object reference。――那个 拿到了P1对象锁的线程,才可以调用P1的同步方法,而对P2而言,P1这个锁与它毫不相干,程序也可能在这种情形下摆脱同步机制的控制,造 成数据混乱:( 2.同步块,示例代码如下: public void method3(SomeObject so) {     synchronized(so)     {        //…..     } } 这时,锁就是so这个对象,谁拿到这个锁谁就可以运行它所控制的那段代码。当有一个明确的对象作为锁时,就可以这样写程序,但当没有明 确的对象作为锁,只是想让一段代码同步时,可以创建一个特殊的instance变量(它得是一个对象)来充当锁: class Foo implements Runnable {         private byte[] lock = new byte[0]; // 特殊的instance变量         Public void methodA()         {            synchronized(lock) { //… }         }         //….. } 注:零长度的byte数组对象创建起来将比任何对象都经济――查看编译后的字节码:生成零长度的byte[]对象只需3条操作码,而Object lock = new Object()则需要7行操作码。 3.将synchronized作用于static 函数,示例代码如下: Class Foo {     public synchronized static void methodAAA()   // 同步的static 函数     {         //….     }     public void methodBBB()     {        synchronized(Foo.class)   // class literal(类名称字面常量)     } }    代码中的methodBBB()方法是把class literal作为锁的情况,它和同步的static函数产生的效果是一样的,取得的锁很特别,是当前调用这 个方法的对象所属的类(Class,而不再是由这个Class产生的某个具体对象了)。 记得在《Effective Java》一书中看到过将 Foo.class和 P1.getClass()用于作同步锁还不一样,不能用P1.getClass()来达到锁这个Class的 目的。P1指的是由Foo类产生的对象。 可以推断:如果一个类中定义了一个synchronized的static函数A,也定义了一个synchronized 的instance函数B,那么这个类的同一对象Obj 在多线程中分别访问A和B两个方法时,不会构成同步,因为它们的锁都不一样。A方法的锁是Obj这个对象,而B的锁是Obj所属的那个Class。 小结如下: 搞清楚synchronized锁定的是哪个对象,就能帮助我们设计更安全的多线程程序。 还有一些技巧可以让我们对共享资源的同步访问更加安全: 1. 定义private 的instance变量+它的 get方法,而不要定义public/protected的instance变量。如果将变量定义为public,对象在外界可以 绕过同步方法的控制而直接取得它,并改动它。这也是JavaBean的标准实现方式之一。 2. 如果instance变量是一个对象,如数组或ArrayList什么的,那上述方法仍然不安全,因为当外界对象通过get方法拿到这个instance对象 的引用后,又将其指向另一个对象,那么这个private变量也就变了,岂不是很危险。 这个时候就需要将get方法也加上synchronized同步,并 且,只返回这个private对象的clone()――这样,调用端得到的就是对象副本的引用了 作者:hanwei_java 来源:CSDN 原文:https://blog.csdn.net/hanwei_java/article/details/79738614 版权声明:本文为博主原创文章,转载请附上博文链接!

auto_answer 2019-12-02 01:50:26 0 浏览量 回答数 0

问题

DRDS 错误代码如何解决?

猫饭先生 2019-12-01 21:21:21 7993 浏览量 回答数 0

问题

【云能量沙龙深圳站】陆晶丹:阿里云开放存储服务API与Web应用案例分享

sleepbird 2019-12-01 20:27:09 18770 浏览量 回答数 23

回答

回 2楼(zc_0101) 的帖子 您好,       您的问题非常好,SQL SERVER提供了很多关于I/O压力的性能计数器,请选择性能计算器PhysicalDisk(LogicalDisk),根据我们的经验,如下指标的阈值可以帮助你判断IO是否存在压力: 1.  % Disk Time :这个是磁盘时间百分比,这个平均值应该在85%以下 2.  Current Disk Queue Length:未完成磁盘请求数量,这个每个磁盘平均值应该小于2. 3.  Avg. Disk Queue Length:磁盘请求队列的平均长度,这个每个磁盘平均值也应该小于2 4.  Disk Transfers/sec:每次磁盘传输数量,这个每个磁盘的最大值应该小于100 5.  Disk Bytes/sec:每次磁盘传入字节数,这个在普通的磁盘上应该在10M左右 6.  Avg. Disk Sec/Read:从磁盘读取的平均时间,这个平均值应该小于10ms(毫秒) 7.  Avg. Disk Sec/Write:磁盘写入的平均时间,这个平均值也应该小于10ms(毫秒) 以上,请根据自己的磁盘系统判断,比如传统的机械臂磁盘和SSD有所不同。 一般磁盘的优化方向是: 1. 硬件优化:比如使用更合理的RAID阵列,使用更快的磁盘驱动器,添加更多的内存 2. 数据库设置优化:比如创建多个文件和文件组,表的INDEX和数据放到不同的DISK上,将数据库的日志放到单独的物理驱动器,使用分区表 3. 数据库应用优化:包括应用程序的设计,SQL语句的调整,表的设计的合理性,INDEX创建的合理性,涉及的范围很广 希望对您有所帮助,谢谢! ------------------------- 回 3楼(鹰舞) 的帖子 您好,      根据您的描述,由于查询产生了副本REDO LOG延迟,出现了架构锁。我们知道SQL SERVER 2012 AlwaysOn在某些数据库行为上有较多变化。我们先看看架构锁: 架构锁分成两类: 1. SCH-M:架构更改锁,主要发生在数据库SCHEMA的修改上,从你的描述看,没有更改SCHEMA,那么可以排除这个因素 2. SCH-S:架构稳定锁,主要发生在数据库的查询编译等活动 根据你的情况,应该属于SCH-S导致的。查询编译活动主要发生有新增加了INDEX, 更新了统计信息,未参数化的SQL语句等等 对于INDEX和SQL语句方面应,我想应该不会有太多问题。 我们重点关注一下统计信息:SQL SERVER 2012 AG副本的统计信息维护有两种: 1. 主体下发到副本 2. 临时统计信息存储在TEMPDB 对于主体下发的,我们可以设置统计信息的更新行为,自动更新时,可以设置为异步的(自动更新统计信息必须首先打开): USE [master] GO ALTER DATABASE [Test_01]     SET AUTO_UPDATE_STATISTICS_ASYNC ON WITH NO_WAIT GO 这样的话查询优化器不等待统计信息更新完成即编译查询。可以优化一下你的BLOCK。 对于临时统计信息存储在TEMPDB里面也是很重要的,再加上ALWAYSON的副本数据库默认是快照隔离,优化TEMPDB也是必要的,关于优化TEPDB这个我想大部分都知道,这里只是提醒一下。 除了从统计信息本身来解决,在查询过程中,可以降低查询的时间,以尽量减少LOCK的时间和范围,这需要优化你的SQL语句或者应用程序。 以上,希望对您有所帮助。谢谢! ------------------------- 回 4楼(leamonjxl) 的帖子 这是一个关于死锁的问题,为了能够提供帮助一些。请根据下列建议进行: 1.    跟踪死锁 2.    分析死锁链和原因 3.    一些解决办法 关于跟踪死锁,我们首先需要打开1222标记,例如DBCC TRACEON(1222,-1), 他将收集的信息写入到死锁事件发生的服务器上的日志文件中。同时建议打开Profiler的跟踪信息: 如果发生了死锁,需要分析死锁发生的根源在哪里?我们不是很清楚你的具体发生死锁的形态是怎么样的。 关于死锁的实例也多,这里不再举例。 这里只是提出一些可以解决的思路: 1.    减少锁的争用 2.    减少资源的访问数 3.    按照相同的时间顺序访问资源 减少锁的争用,可以从几个方面入手 1.    使用锁提示,比如为查询语句添加WITH (NOLOCK), 但这还取决于你的应用是否允许,大部分分布式的系统都是可以加WITH (NOLOCK), 金融行业可能需要慎重。 2.    调整隔离级别,使用MVCC,我们的数据库默认级别是READ COMMITED. 建议修改为读提交快照隔离级别,这样的话可以尽量读写不阻塞,只不过MVCC的ROW VERSION保存到TEMPDB下面,需要维护好TEMPDB。当然如果你的整个数据库隔离级别可以设置为READUNCOMMINTED,这些就不必了。 减少资源的访问数,可以从如下几个方面入手: 1.    使用聚集索引,非聚集INDEX的叶子页面与堆或者聚集INDEX的数据页面分离。因此,如果对非聚集INDEX 操作的话,会产生两个锁,一个是基本表,一个是非聚集INDEX。而聚集INDEX就不一样,聚集INDEX的叶子页面和表的数据页面相同,他只需要一个LOCK。 2.    查询语句尽量使用覆盖INDEX, 使用全覆盖INDEX,就不需要访问基本表。如果没有全覆盖,还会通过RID或者CLUSTER INDEX访问基本表,这样产生的LOCK可能会与其他SESSION争用。 按照相同的时间顺序访问资源: 确保每个事务按照相同的物理顺序访问资源。两个事务按照相同的物理顺序访问,第一个事务会获得资源上的锁而不会被第二个事务阻塞。第二个事务想获得第一个事务上的LOCK,但被第一个事务阻塞。这样的话就不会导致循环阻塞的情况。 ------------------------- 回 4楼(leamonjxl) 的帖子 两种方式看你的业务怎么应用。这里不仅是分表的问题,还可能存在分库,分服务器的问题。取决与你的架构方案。 物理分表+视图,这是一种典型的冷热数据分离的方案,大致的做法如下: 1.    保留最近3个月的数据为当前表,也即就是我们说的热数据 2.    将其他数据按照某种规则分表,比如按照年或者季度或者月,这部分是相对冷的数据 分表后,涉及到几个问题: 第一问题是,转移数据的过程,一般是晚上业务比较闲来转移,转移按照一定的规则来做,始终保持3个月,这个定时任务本身也很消耗时间 再者,关于查询部分,我想你们的数据库服务器应该通过REPLICATION做了读写分离的吧,主库我觉得压力不会太大,主要是插入或者更新,只读需要做视图来包含全部的数据,但通过UNION ALL所有分表的数据,最后可能还是非常大,在某些情况下,性能不一定好。这个是不是业务上可以解决。比如,对于1年前的历史数据,放在单独的只读上,相对热的数据放在一起,这样压力也会减少。 分区表的话,因为涉及到10亿数据,要有好的分区方案,相对比较简单一点。但对于10亿的大表,始终是个棘手的问题,无论分多少个分区,单个服务器的资源也是有限的。可扩展性方面也存在问题,比如在只读上你没有办法做服务器级别的拆分了。这可能也会造成瓶颈。 现在很多企业都在做分库分表,这些的要解决一些高并发,数据量大的问题。不知是否考虑过类似于中间件的方案,比如阿里巴巴的TDDL类似的方案,如果你有兴趣,可以查询相关资料。 ------------------------- 回 9楼(jiangnii) 的帖子 阿里云数据库不仅提供一个数据库,还提供数据库一种服务。阿里云数据库不仅简化了基础架构的部署,还提供了数据库高可用性架构,备份服务,性能诊断服务,监控服务,专家服务等等,保证用户放心、方便、省心地使用数据库,就像水电一样。以前的运维繁琐的事,全部由阿里云接管,用户只需要关注数据库的使用和具体的业务就好。 关于优化和在云数据库上处理大数据量或复杂的数据操作方面,在云数据库上是一样的,没有什么特别的地方,不过我们的云数据库是使用SSD磁盘,这个比普通的磁盘要快很多,IO上有很大的优势。目前单个实例支持1T的数据量大小。陆续我们会推出更多的服务,比如索引诊断,连接诊断,容量分析,空间诊断等等,这些工作可能是专业的DBA才能完成的,以后我们会提供自动化的服务来为客户创造价值,希望能帮助到客户。 谢谢! ------------------------- 回 12楼(daniellin17) 的帖子 这个问题我不知道是否是两个问题,一个是并行度,另一个是并发,我更多理解是吞吐量,单就并行度而言。 提高并行度需要考虑的因素有: 1.    可用于SQL SERVER的CPU数量 2.    SQL SERVER的版本(32位/64位) 3.    可用内存 4.    执行的查询类型 5.    给定的流中处理的行数 6.    活动的并发连接数量 7.    sys.configurations参数:affinity mask/max server memory (MB)/ max degree of parallelism/ cost threshold for parallelism 以DOP的参数控制并行度为例,设置如下: SELECT * FROM sys.configurations WITH (NOLOCK) WHERE name = 'max degree of parallelism' EXEC sp_configure 'max degree of parallelism',2 RECONFIGURE WITH OVERRIDE 经过测试,DOP设置为2是一个比较适中的状态,特别是OLTP应用。如果设置高了,会产生较多的SUSPEND进程。我们可以观察到资源等待资源类型是:CXPACKET 你可以用下列语句去测试: DBCC SQLPERF('sys.dm_os_wait_stats',CLEAR) SELECT * FROM sys.dm_os_wait_stats WITH (NOLOCK) ORDER BY 2 DESC ,3 DESC 如果是吞吐量的话。优化的范围就很广了。优化是系统性的。硬件配置我们选择的话,大多根据业务量来预估,然后考虑以下: 1.    RAID的划分,RAID1适合存放事务日志文件(顺序写),RAID10/RAID5适合做数据盘,RAID10是条带化并镜像,RAID5条带化并奇偶校验 2.    数据库设置,比如并行度,连接数,BUFFER POOL 3.    数据库文件和日志文件的存放规则,数据库文件的多文件设置规则 4.    TEMPDB的优化原则,这个很重要的 5.    表的设计方面根据业务类型而定 6.    CLUSTERED INDEX和NONCLUSTERED INDEX的设计 7.    阻塞分析 8.    锁和死锁分析 9.    执行计划缓冲分析 10.    存储过程重编译 11.    碎片分析 12.    查询性能分析,这个有很多可以优化的方式,比如OR/UNION/类型转换/列上使用函数等等 我这里列举一个高并发的场景: 比如,我们的订单,比如搞活动的时候,订单刷刷刷地增长,单个实例可能每秒达到很高很高,我们分析到最后最常见的问题是HOT PAGE问题,其等待类型是PAGE LATCH竞争。这个过程可以这么来处理,简单列几点,可以参考很多涉及高并发的案例: 1.    数据库文件和日志文件分开,存放在不同的物理驱动器磁盘上 2.    数据库文件需要与CPU个数形成一定的比例 3.    表设计可以使用HASH来作为表分区 4.    表可以设置无序的KEY/INDEX,比如使用GUID/HASH VALUE来定义PRIMARY KEY CLUSTER INDEX 5.    我们不能将自增列设计为聚集INDEX 这个场景只是针对高并发的插入。对于查询而言,是不适合的。但这些也可能导致大量的页拆分。只是在不同的场景有不同的设计思路。这里抛砖引玉。 ------------------------- 回 13楼(zuijh) 的帖子 ECS上现在有两种磁盘,一种是传统的机械臂磁盘,另一种是SSD,请先诊断你的IO是否出现了问题,本帖中有提到如何判断磁盘出现问题的相关话题,请参考。如果确定IO出现问题,可以尝试使用ECS LOCAL SSD。当然,我们欢迎你使用云数据库的产品,云数据库提供了很多有用的功能,比如高可用性,灵活的备份方案,灵活的弹性方案,实用的监控报警等等。 ------------------------- 回 17楼(豪杰本疯子) 的帖子 我们单个主机或者单个实例的资源总是有限的,因为涉及到很大的数据量,对于存储而言是个瓶颈,我曾使用过SAN和SAS存储,SAN存储的优势确实可以解决数据的灵活扩展,但是SAN也分IPSAN和FIBER SAN,如果IPSAN的话,性能会差一些。即使是FIBER SAN,也不是很好解决性能问题,这不是它的优势,同时,我们所有DB SERVER都连接到SAN上,如果SAN有问题,问题涉及的面就很广。但是SAS毕竟空间也是有限的。最终也会到瓶颈。数据量大,是造成性能问题的直接原因,因为我们不管怎么优化,一旦数据量太大,优化的能力总是有限的,所以这个时候更多从架构上考虑。单个主机单个实例肯定是抗不过来的。 所以现在很多企业在向分布式系统发展,对于数据库而言,其实有很多形式。我们最常见的是读写分离,比如SQL SERVER而言,我们可以通过复制来完成读写分离,SQL SERVER 2012及以后的版本,我们可以使用ALWAYSON来实现读写分离,但这只能解决性能问题,那空间问题怎么解决。我们就涉及到分库分表,这个分库分表跟应用结合得紧密,现在很多公司通过中间件来实现,比如TDDL。但是中间件不是每个公司都可以玩得转的。因此可以将业务垂直拆分,那么DB也可以由此拆分开来。举个简单例子,我们一个典型的电子商务系统,有订单,有促销,有仓库,有配送,有财务,有秒杀,有商品等等,很多公司在初期,都是将这些放在一个主机一个实例上。但是这些到了一定规模或者一定数据量后,就会出现性能和硬件资源问题,这时我们可以将它们独立一部分获完全独立出来。这些都是一些好的方向。希望对你有所帮助。 ------------------------- 回 21楼(dt) 的帖子 问: 求大数据量下mysql存储,优化方案 分区好还是分表好,分的过程中需要考虑事项 mysql高并发读写的一些解决办法 答: 分区:对于应用来说比较简单,改造较少 分表: 应用需较多改造,优点是数据量太大的情况下,分表可以拆分到多个实例上,而分区不可以。 高并发优化,有两个建议: 1.    优化事务逻辑 2.    解决mysql高并发热点,这个可以看看阿里的一个热点补丁: http://www.open-open.com/doc/view/d58cadb4fb68429587634a77f93aa13f ------------------------- 回 23楼(aelven) 的帖子 对于第一个问题.需要看看你的数据库架构是什么样的?比如你的架构具有高可用行?具有读写分离的架构?具有群集的架构.数据库应用是否有较冷门的功能。高并发应该不是什么问题。可扩展性方面需要考虑。阿里云数据库提供了很多优势,比如磁盘是性能超好的SSD,自动转移的高可用性,没有任何单点,自动灵活的备份方案,实用的监控报警,性能监控服务等等,省去DBA很多基础性工作。 你第二个问题,看起来是一个高并发的场景,这种高并发的场景容易出现大量的LOCK甚至死锁,我不是很清楚你的业务,但可以建议一下,首先可以考虑快照隔离级别,实现行多版本控制,让读写不要阻塞。至于写写过程,需要加锁的粒度降低最低,同时这种高并发也容易出现死锁,关于死锁的分析,本帖有提到,请关注。 第三个问题,你用ECS搭建自己的应用也是可以的,RDS数据库提供了很多功能,上面已经讲到了。安全问题一直是我们最看重的问题,肯定有超好的防护的。 ------------------------- 回 26楼(板砖大叔) 的帖子 我曾经整理的关于索引的设计与规范,可以供你参考: ----------------------------------------------------------------------- 索引设计与规范 1.1    使用索引 SQL SERVER没有索引也可以检索数据,只不过检索数据时扫描这个表而异。存储数据的目的,绝大多数都是为了再次使用,而一般数据检索都是带条件的检索,数据查询在数据库操作中会占用较大的比例,提高查询的效率往往意味着整个数据库性能的提升。索引是特定列的有序集合。索引使用B-树结构,最小优化了定位所需要的键值的访问页面量,包含聚集索引和非聚集索引两大类。聚集索引与数据存放在一起,它决定表中数据存储的物理顺序,其叶子节点为数据行。 1.2    聚集索引 1.2.1    关于聚集索引 没聚集索引的表叫堆。堆是一种没有加工的数据,以行标示符作为指向数据存储位置的指针,数据没有顺序。聚集索引的叶子页面和表的数据页面相同,因此表行物理上按照聚集索引列排序,表数据的物理顺序只有一种,所以一个表只有一个聚集索引。 1.2.2    与非聚集索引关系 非聚集索引的一个索引行包含指向表对应行的指针,这个指针称为行定位器,行定位器的值取决于数据页保存为堆还是被聚集。若是堆,行定位器指向的堆中数据行的行号指针,若是聚集索引表,行定位器是聚集索引键值。 1.2.3    设计聚集索引注意事项     首先创建聚集索引     聚集索引上的列需要足够短     一步重建索引,不要使用先DROP再CREATE,可使用DROP_EXISTING     检索一定范围和预先排序数据时使用,因为聚集索引的叶子与数据页面相同,索引顺序也是数据物理顺序,读取数据时,磁头是按照顺序读取,而不是随机定位读取数据。     在频繁更新的列上不要设计聚集索引,他将导致所有的非聚集所有的更新,阻塞非聚集索引的查询     不要使用太长的关键字,因为非聚集索引实际包含了聚集索引值     不要在太多并发度高的顺序插入,这将导致页面分割,设置合理的填充因子是个不错的选择 1.3    非聚集索引 1.3.1    关于非聚集索引 非聚集索引不影响表页面中数据的顺序,其叶子页面和表的数据页面时分离的,需要一个行定位器来导航数据,在将聚集索引时已经有说明,非聚集索引在读取少量数据行时特别有效。非聚集索引所有可以有多个。同时非聚集有很多其他衍生出来的索引类型,比如覆盖索引,过滤索引等。 1.3.2    设计非聚集索引     频繁更新的列,不适合做聚集索引,但可以做非聚集索引     宽关键字,例如很宽的一列或者一组列,不适合做聚集索引的列可作非聚集索引列     检索大量的行不宜做非聚集索引,但是可以使用覆盖索引来消除这种影响 1.3.3    优化书签查找 书签会访问索引之外的数据,在堆表,书签查找会根据RID号去访问数据,若是聚集索引表,一般根据聚集索引去查找。在查询数据时,要分两个部分来完成,增加了读取数据的开销,增加了CPU的压力。在大表中,索引页面和数据页面一般不会临近,若数据只存在磁盘,产生直接随机从磁盘读取,这导致更多的消耗。因此,根据实际需要优化书签查找。解决书签查找有如下方法:     使用聚集索引避免书签查找     使用覆盖索引避免书签查找     使用索引连接避免数据查找 1.4    聚集与非聚集之比较 1.4.1    检索的数据行 一般地,检索数据量大的一般使用聚集索引,因为聚集索引的叶子页面与数据页面在相同。相反,检索少量的数据可能非聚集索引更有利,但注意书签查找消耗资源的力度,不过可考虑覆盖索引解决这个问题。 1.4.2    数据是否排序 如果数据需要预先排序,需要使用聚集索引,若不需要预先排序就那就选择聚集索引。 1.4.3    索引键的宽度 索引键如果太宽,不仅会影响数据查询性能,还影响非聚集索引,因此,若索引键比较小,可以作为聚集索引,如果索引键够大,考虑非聚集索引,如果很大的话,可以用INCLUDE创建覆盖索引。 1.4.4    列更新的频度 列更新频率高的话,应该避免考虑所用非聚集索引,否则可考虑聚集索引。 1.4.5    书签查找开销 如果书签查找开销较大,应该考虑聚集索引,否则可使用非聚集索引,更佳是使用覆盖索引,不过得根据具体的查询语句而看。 1.5    覆盖索引 覆盖索引可显著减少查询的逻辑读次数,使用INCLUDE语句添加列的方式更容易实现,他不仅减小索引中索引列的数据,还可以减少索引键的大小,原因是包含列只保存在索引的叶子级别上,而不是索引的叶子页面。覆盖索引充当一个伪的聚集索引。覆盖索引还能够有效的减少阻塞和死锁的发生,与聚集索引类似,因为聚集索引值发生一次锁,非覆盖索引可能发生两次,一次锁数据,一次锁索引,以确保数据的一致性。覆盖索引相当于数据的一个拷贝,与数据页面隔离,因此也只发生一次锁。 1.6    索引交叉 如果一个表有多个索引,那么可以拥有多个索引来执行一个查询,根据每个索引检索小的结果集,然后就将子结果集做一个交叉,得到满足条件的那些数据行。这种技术可以解决覆盖索引中没有包含的数据。 1.7    索引连接 几乎是跟索引交叉类似,是一个衍生品种。他将覆盖索引应用到交叉索引。如果没有单个覆盖索引查询的索引而多个索引一起覆盖查询,SQL SERVER可以使用索引连接来完全满足查询而不需要查询基础表。 1.8    过滤索引 用来在可能没有好的选择性的一个或者多个列上创建一个高选择性的关键字组。例如在处理NULL问题比较有效,创建索引时,可以像写T-SQL语句一样加个WHERE条件,以排除某部分数据而检索。 1.9    索引视图 索引视图在OLAP系统上可能有胜算,在OLTP会产生过大的开销和不可操作性,比如索引视图要求引用当前数据库的表。索引视图需要绑定基础表的架构,索引视图要求企业版,这些限制导致不可操作性。 1.10    索引设计建议 1.10.1    检查WHERE字句和连接条件列 检查WHERE条件列的可选择性和数据密度,根据条件创建索引。一般地,连接条件上应当考虑创建索引,这个涉及到连接技术,暂时不说明。 1.10.2    使用窄的索引 窄的索引有可减少IO开销,读取更少量的数据页。并且缓存更少的索引页面,减少内存中索引页面的逻辑读取大小。当然,磁盘空间也会相应地减少。 1.10.3    检查列的唯一性 数据分布比较集中的列,种类比较少的列上创建索引的有效性比较差,如果性别只有男女之分,最多还有个UNKNOWN,单独在上面创建索引可能效果不好,但是他们可以为覆盖索引做出贡献。 1.10.4    检查列的数据类型 索引的数据类型是很重要的,在整数类型上创建的索引比在字符类型上创建索引更有效。同一类型,在数据长度较小的类型上创建又比在长度较长的类型上更有效。 1.10.5    考虑列的顺序 对于包含多个列的索引,列顺序很重要。索引键值在索引上的第一上排序,然后在前一列的每个值的下一列做子排序,符合索引的第一列通常为该索引的前沿。同时要考虑列的唯一性,列宽度,列的数据类型来做权衡。 1.10.6    考虑索引的类型 使用索引类型前面已经有较多的介绍,怎么选择已经给出。不再累述。 ------------------------- 回 27楼(板砖大叔) 的帖子 这两种都可以吧。看个人的喜好,不过微软现在的统一风格是下划线,比如表sys.all_columns/sys.tables,然后你再看他的列全是下划线连接,name     /object_id    /principal_id    /schema_id    /parent_object_id      /type    /type_desc    /create_date    /modify_date 我个人的喜好也是喜欢下划线。    

石沫 2019-12-02 01:34:30 0 浏览量 回答数 0

问题

【面试必备】2020最新Java集合容器面试题

剑曼红尘 2020-03-24 14:00:04 7 浏览量 回答数 1

问题

第6篇 指针数组字符串(下)补充:报错

kun坤 2020-06-08 11:02:03 3 浏览量 回答数 1

问题

Vue面试题汇总【精品问答】

问问小秘 2020-05-25 18:02:28 11132 浏览量 回答数 2

问题

【精品问答】关于Java,那些入门级的面试题

问问小秘 2020-03-27 18:39:09 1073 浏览量 回答数 3

问题

SaaS模式云数据仓库MaxCompute 百问百答合集(持续更新20200921)

亢海鹏 2020-05-29 15:10:00 19050 浏览量 回答数 5
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站