以电定热可以做什么

在这个信息时代高速发展的情况下，很多人会对自己该往哪个方向发展感到迷茫，下面我就浅显的给大家介绍一下五大流行区域的发展前景。大数据的发展前景：当前大数据行业真的是人才稀缺吗?学了几年后，大数据行业会不会产能过剩?大数据行业最终需要什么样的人才?接下来就带你们看看分析结果：当前大数据行业真的是人才稀缺吗?对!未来人才缺口150万，数据分析人才最稀缺。先看大数据人才缺口有多大?根据LinkedIn(领英)发布的《2016年中国互联网最热职位人才报告》显示，研发工程师、产品经理、人力资源、市场营销、运营和数据分析是当下中国互联网行业需求最旺盛的六类人才职位。其中数据分析人才最为稀缺、供给指数最低。同时，数据分析人才跳槽速度也最快，平均跳槽速度为19.8个月。而清华大学计算机系教授武永卫去年透露了一组数据：未来3-5年，中国需要180万数据人才，但目前只有约30万人。大数据行业未来会产能过剩吗?提供大数据技术与应用服务的第三方公司面临调整，未来发展会趋集中关于“大数据概念是否被过度炒作”的讨论，其实2013年的夏季达沃斯就有过。彼时支持“炒作”观点的现场观众达54.5%。对此，持反对意见的北京大学光华管理学院副教授苏萌提出了三个理由：不同机构间的数据还未真正流动起来，目前还只是数据“孤岛”;完整的生态产业链还未形成，尽管通过行为数据分析已能够分辨出一个消费者的喜好，但从供应到购买的链条还没建成;数据分析人才仍然极度匮乏。4年之后，舆论热点已经逐渐从大数据转向人工智能，大数据行业也历经整合。近一年间，一些大数据公司相继出现裁员、业务大调整等情况，部分公司出现亏损。那都是什么公司面临危机呢?基于数据归属，涉及大数据业务的公司其实有两类：一类是自身拥有数据的甲方公司，如亚马逊、阿里巴巴等;另一类是整合数据资源，提供大数据技术与应用服务的第三方公司。目前行业整合出现盈利问题的公司多集中在第三方服务商。对此，LinkedIn(领英)中国技术副总裁王迪表示，第三方服务商提供的更多的是技术或平台，大数据更多还是让甲方公司获益。在王迪看来，大数据业务要产生规模效益，至少要具备三点：算法、计算平台以及数据本身。“第三方大数据创业公司在算法上有一技之长，而计算能力实际上已经匀化了，传统企业如果用好了，和大数据创业公司没有区别，甚至计算能力更强，而数据获取方面，很多数据在传统行业内部并没有共享出来，第三方大数据公司获取这些数据是比较困难的，最后可能谁有数据，谁产生的价值更高。”说白了，数据为王。在2013年，拿到千万级A轮融资的大数据企业不足10家，到2015年，拿到千万级以上A轮融资的企业已经超过30家。直到2016年互联网资本寒冬，大数据行业投资热度有所减退，大数据行业是否也存在产能过剩?王迪认为，目前的行业整合属于正常现象，“经过市场的优胜劣汰，第三方服务领域会出现一些做得比较好的公司，其他公司可能被淘汰或转型做一些垂直行业应用。从社会来看，总的需求量一定是增加的，而对于供给侧，经过行业自然的洗牌，最终会集中在几家优秀的行业公司。”需要什么样的大数据人才?今年3月份，教育部公布了第二批获准开设“数据科学与大数据技术”的高校名单，加上第一批获批的北京大学、对外经济贸易大学、中南大学，一共35所高校获批该专业。今年开始，部分院校将招收第一届大数据专业本科生。大数据人才培养涉及到两方面问题：交叉性学科的人才培养方案是否与市场需求相匹配;学科建设的周期与行业快速更新之间的差距怎样弥合。对于第一个问题，“电商热”时期开设的电子商务专业是一个可吸取经验的样本。2000年，教育部高教司批准了第一批高校开设电子商务本科专业。作为一个复合型专业，电子商务的本科教学涵盖了管理、技术、营销三方面的课程。电子商务领域人才需求量大，但企业却无法从电子商务专业中找到合适的人才，原因何在?职业规划专家姜萌认为，并不是某一个专业对应一个行业热点，而是一个专业集群对应一个行业热点。“比如电子商务专业，我们到电子商务公司里会发现，不是学电子商务的人在做这些工作，而是每个专业各司其职，比如计算机、设计、物流管理、营销、广告、金融等等。现在行业的复合型工作都是由一个专业集群来完成的，而不是一个人来复合一堆专业特点。”大数据专业的人才培养也同样走复合型路线，复旦大学大数据学院的招生简章显示，学院本科人才培养以统计学、计算机科学和数学为三大基础支撑性学科，以生物学、医学、环境科学、经济学、社会学、管理学等为应用拓展性学科，具备典型的交叉学科特征。LinkedIn(领英)中国技术副总裁王迪指出，“从企业应用的角度来看，大数据行业里从事相关职能的同学背景是各异的，大数据作为一个人才培养方向还在探索中，在这个阶段，高校尝试开设硕士课程是很好的实践，但开设一类的本科专业还为时过早。”另一方面，专业人才培养的周期较长，而行业热点不断更新轮替，中间产生的时间差使得新兴专业的志愿填报具备了一定风险。王迪认为，“从今天的产业实践上看，大数据领域依然是从现有专业中挑选人才，教育和市场发展总是有一定差距的，学生本科四年，加上硕士阶段已经是七年之后的事情了，产业已经演进了很多，而教学大纲并不会跟进得那么快。”因此，尽管大数据的应用前景毋庸置疑，但在人才培养层面，复合型人才培养方案会不会重走电子商务专业的老路?学校教育如何赶上行业发展速度?这些都是值得进一步商榷的问题。面对热门专业，志愿填报需要注意啥?了解了大数据行业、公司和大数据专业后，姜萌对于考生填报像大数据相关的热门专业，提出了几条建议：报考热的专业和就业热的专业并不一定是重合的，比如软件、计算机、金融，这些专业的就业率实际并没有那么高，地质勘探、石油、遥感等专业，虽然报考上是冷门，但行业需求大，就业率更高。选择热门专业，更需要考虑就业质量。专业就业好，是统计学意义，指的是平均收入水平高，比如金融专业的收入，比其他纯文科专业的平均收入较高，但落实到个体层面，就业情况就不一样了，尤其像金融专业是典型的名校高学历好就业，但对于考试成绩较低的同学来说，如果去一些普通院校、专科院校学习金融，最后就业情况可能还不如会计专业。志愿填报，除了专业，城市因素也很重要：如果想从事金融、互联网的工作，更适合去一线城市，如果是去三、四线城市的学生可以考虑应用面比较广的专业，就是各行各业都能用到的专业，比如会计专业，专科层次的会计和985层次的会计都有就业渠道。如果先选择报考城市，也可以针对所在城市的行业特点选择专业，比如沿海城市外贸相对发达，选择国际贸易、外语类专业就业情况更好，比如武汉有光谷，选择光电类专业更好就业。最终家长和考生更需要考虑个人与专业匹配的问题，金融、计算机等热门专业不是所有人都适合学，好专业不见得对所有个体都是好的。java的发展前景：由于Java的诸多优点，Java的发展前景十分广泛。比如，在我们中国的市场，Java无论在企业级应用，还是在面向大众的服务方面都取得了不少进展，在中国的电信、金融等关键性业务中发挥着举足轻重的作用。由于SUN、TBM、Oracle等国际厂商相继推出各种基于Java技术的应用服务器以及各种应用软件，推动了Java在金融、电信、制造等领域日益广泛的应用，如清华大学计算机系利用Java、XML和Web技术研制开发了多个软件平台，东方科技的TongWeb、中创的Inforweb等J2EE应用服务器。由此可见，在巨大市场需求下，企业对于Java人才的渴求已经是不争的事实。你问我火了这么多年的Java语言的发展前景怎么样？那来看看吧Java在WEB、移动设备以及云计算方面前景广阔，随着云计算以及移动领域的扩张，更多的企业在考虑将其应用部署在Java平台上。无论是本地主机，公共云，Java都是目前最适合的选择。;另外在Oracle的技术投资担保下，Java也是企业在云应用方面回避微软平台、在移动应用方面回避苹果公司的一个最佳选择。Java可以参与制作大部分网络应用程序系统，而且与如今流行的WWW浏览器结合很好，这一优点将促进Java的更大范围的推广。因为在未来的社会，信息将会传送的更加快速，这将推动程序向WEB程序方向发展，由于Java具有编写WEB程序的能力，并且Java与浏览器结合良好，这将使得Java前景充满光明的发展。Python的发展前景：Python程序员的发展前景是怎样的？随着Python的技术的流行， Python在为人们带来工作与生活上的便捷后，关注者们开始慢慢关心Python的发展前景与方向。从自身特性看Python发展Python自身强大的优势决定其不可限量的发展前景。Python作为一种通用语言，几乎可以用在任何领域和场合，角色几乎是无限的。Python具有简单、易学、免费、开源、可移植、可扩展、可嵌入、面向对象等优点，它的面向对象甚至比java和C#、.net更彻底。它是一种很灵活的语言，能帮你轻松完成编程工作。强大的类库支持，使编写文件处理、正则表达式，网络连接等程序变得相当容易。能运行在多种计算机平台和操作系统中，如各位unix，windows，MacOS,OS/2等等，并可作为一种原型开发语言，加快大型程序的开发速度。从企业应用来看Python发展Python被广泛的用在Web开发、运维自动化、测试自动化、数据挖掘等多个行业和领域。一项专业调查显示，75%的受访者将Python视为他们的主要开发语言，反之，其他25%受访者则将其视为辅助开发语言。将Python作为主要开发语言的开发者数量逐年递增，这表明Python正在成为越来越多开发者的开发语言选择。目前，国内不少大企业都已经使用Python如豆瓣、搜狐、金山、腾讯、盛大、网易、百度、阿里、淘宝、热酷、土豆、新浪、果壳等;国外的谷歌、NASA、YouTube、Facebook、工业光魔、红帽等都在应用Python完成各种各样的任务。从市场需求与薪资看Python发展Python得到越来越多公司的青睐，使得Python人才需求逐年增加，从市场整体需求来看，Python在招聘市场上的流行程度也是在逐步上升的，工资水平也是水涨船高。据统计Python平均薪资水平在12K，随着经验的提升，薪资也是逐年增长。学习Python的程序员，除去Python开发工程师、Python高级工程师、Python自动化测试外，也能够朝着Python游戏开发工程师、SEO工程师、Linux运维工程师等方向发展，发展方向较为多元化。随着Python的流行，带动的是它的普及以及市场需求量，所以现在学习Python是个不错的时机。区块链的发展前景：区块链开发 ? 155---0116---2665 ?可是区块链技术到底是什么，大多数人都是模糊没有概念。通俗来讲，如果我们把数据库假设成一本账本，读写数据库就可以看做一种记账的行为，区块链技术的原理就是在一段时间内找出记账最快最好的人，由这个人来记账，然后将账本的这一页信息发给整个系统里的其他所有人。区块链技术也称分布式账本（或账簿）技术，属于互联网数据库技术，由参与者共同完成数据库记录，特点是去中心化和公开透明。此外，在每个区块的信息写入并获得认可后，整个区块链数据库完整保存在互联网的节点中，难以被修改，因此数据库的安全性极高。人们普遍认为，区块链技术是实现数字产品（如货币和知识产权）快速、安全和透明地对等（P2P）转账或转让的重要手段。在以色列Zen Protocol公司，区块链应用软件开发专家阿希尔·曼宁介绍说，他们公司正在开发Zen区块链平台，其将用于支持金融产品在无中介的环境下自动和自由交易。通常，人们将钱存放在银行，依靠银行管理自己的资金。但是，在支配资金时往往会受到银行规定的限制，或在汇款时存在耗时长、费用高等问题。区块链技术平台将让人们首次拥有自己管理和支配钱财的能力，他相信去中心化金融管理体系具有广阔的市场，有望极大地改变传统的金融市场。2018年伊始这一轮区块链的热潮，主要起源于虚拟货币的炒作热情。站在风口，区块链技术被认为是继蒸汽机、电力、互联网之后，下一代颠覆性的核心技术。很多人不禁要问“区块链又和比特币又是什么关系？”记者查询了大量资料发现，比特币2009年被一位名叫中本聪的人提出，之后比特币这套去中心化的机制一直稳定运行，这引起很多人对这套历史上并不存在的运行机制强烈关注。于是人们把从比特币技术抽象提取出来的技术运用于其他领域，称之为区块链。这过程就好像人们先发明了面条，然后人们发现其背后面粉不仅可以做面条还可以做馒头、面包。比特币是面条，区块链是面粉。也就是说，区块链和比特币的关系即比特币算是区块链技术的一种应用，或者说一种使用了区块链技术的产品形态。而说到区块链不得不说的就是ICO，它是一种公开发行的初始数字货币。对于投资人来说，出于对市场信号的敏感和长期关注价值投资项目，目前炙手可热的区块链也成为诸多投资人关注的新兴项目之一。“区块链对于我们来说就是省去了中间环节，节约了交易成本，节省了交易时间，但是目前来看各方面环境还不够成熟，有待观望。”一位投资人这样说道。记者发现，在春节期间，不少互金圈的朋友熬夜到凌晨进入某个探讨区块链的微信群热聊，此群还吸引了不少知名人士，诸如明星加入，同时还有大咖在群里解读区块链的投资方式和未来发展等等。一时间，关于区块链的讨论群接二连三出现，也引发了各个行业对区块链的关注。出于对于区块链技术懵懂的状态，记者追问了身边的一些互金圈的朋友，为何如此痴迷区块链？多数朋友认为“区块链能赚钱，抱着试试看的心态，或许能像之前比特币一样从中获取收益。”显然，区块链技术具有广阔的应用潜力，但是在其逐步进入社会改善民众生活的过程中，也面临许多的问题，需要积极去寻求相应的对策，最终让其发挥出潜力。只有这样，10年或20年后人们才能真正享受区块链技术创造的美好环境。人工智能的发展前景：人工智能产业是智能产业发展的核心，是其他智能科技产品发展的基础，国内外的高科技公司以及风险投资机构纷纷布局人工智能产业链。科技部部长万钢3月10日表示，加快实施新一代人工智能科学基础的关键技术系统集成研发，使那些研发成果尽快能够进入到开放平台，在开放使用中再一次把它增强完善。万钢称，马上就要发布人工智能项目指南和细则，来突破基础前沿理论关键部分的技术。人工智能发展趋势据前瞻产业研究院《人工智能行业市场前瞻与投资战略规划分析报告》指出，2017年中国人工智能核心产业规模超过700亿元，随着国家规划的出台，各地人工智能相关建设将逐步启动，预计到2020年，中国人工智能核心产业规模将超过1600亿元，增长率达到26.2%。报告认为，从产业投资回报率分析，智能安防、智能驾驶等领域的快速发展都将刺激计算机视觉分析类产品的需求，使得计算机视觉领域具备投资价值；而随着中国软件集成水平和人们生活水平的提高，提供教育、医疗、娱乐等专业化服务的服务机器人和智能无人设备具备投资价值。人工智能现状当前，人工智能受到的关注度持续提升，大量的社会资本和智力、数据资源的汇集驱动人工智能技术研究不断向前推进。从发展层次来看，人工智能技术可分为计算智能、感知智能和认知智能。当前，计算智能和感知智能的关键技术已经取得较大突破，弱人工智能应用条件基本成熟。但是，认知智能的算法尚未突破，前景仍不明朗。今年，随着智力资源的不断汇集，人工智能核心技术的研究重点可能将从深度学习转为认知计算，即推动弱人工智能向强人工智能不断迈进。一方面，在人工智能核心技术方面，在百度等大型科技公司和北京大学、清华大学等重点院校的共同推动下，以实现强人工智能为目标的类脑智能有望率先突破。另一方面，在人工智能支撑技术方面，量子计算、类脑芯片等核心技术正处在从科学实验向产业化应用的转变期，以数据资源汇集为主要方向的物联网技术将更加成熟，这些技术的突破都将有力推动人工智能核心技术的不断演进。工业大数据2022 年我国工业大数据有望突破 1200 亿元， 复合增速 42%。 工业大数据是提升制造智能化水平，推动中国制造业转型升级的关键动力，具体包括企业信息化数据、工业物联网数据，以及外部跨界数据。其中，企业信息化和工业物联网中机器产生的海量时序数据是工业数据的主要来源。工业大数据不仅可以优化现有业务，实现提质增效，而且还有望推动企业业务定位和盈利模式发生重大改变，向个性化定制、智能化生产、网络化协同、服务化延伸等智能化场景转型。预计到 2022 年，中国工业大数据市场规模有望突破 1200亿元，年复合增速 42%。IT的未来是人工智能这是一个指数级增长的时代。过去几十年，信息技术的进步相当程度上归功于芯片上晶体管数目的指数级增加，及由此带来的计算力的极大提升。这就是所谓的摩尔定律。在互联网时代，互联的终端数也是超线性的增长，而网络的效力大致与联网终端数的平方成正比。今天，大数据时代产生的数据正在呈指数级增加。在指数级增长的时代，我们可能会高估技术的短期效应，而低估技术的长期效应。历史的经验告诉我们，技术的影响力可能会远远的超过我们的想象。未来的计算能力人工智能需要强大的计算能力。计算机的性能过去30年提高了一百万倍。随着摩尔定律逐渐趋于物理极限，未来几年，我们期待一些新的技术突破。先谈一下类脑计算。传统计算机系统，长于逻辑运算，不擅长模式识别与形象思维。构建模仿人脑的类脑计算机芯片，我们今天可以以极低的功耗，模拟100万个神经元，2亿5千万个神经突触。未来几年，我们会看到类脑计算机的进一步的发展与应用随着互联网的普及、传感器的泛在、大数据的涌现、电子商务的发展、信息社区的兴起，数据和知识在人类社会、物理空间和信息空间之间交叉融合、相互作用，人工智能发展所处信息环境和数据基础发展了巨大的变化。伴随着科学基础和实现载体取得新的突破，类脑计算、深度学习、强化学习等一系列的技术萌芽预示着内在动力的成长，人工智能的发展已进入一个新的阶段。发展发展前景好，代表你现在学习会比后来者起步快，占有更大的优势，当然，你也要明白兴趣是最好的老师，选择自己感兴趣的相信你学的会更加而牢固。记住，最重要的一点：方向最重要！！！希望大家多多关注. ，加微信zhanglindashuju 可以获取更多资料哦作者：失色的瞳孔链接：https://juejin.im/post/5b1a6531e51d45067e6fc24a来源：掘金著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

回 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 我个人的喜好也是喜欢下划线。