我们在不断的更新，以保证软件能够兼容各个类型的网页类型!

简单易学，通过可视化界面、鼠标点击即可采集数据、向导模式，用户无需任何技术基础，输入网址，一键提取数据。代码小白的福音

内置大量网站采集模板，覆盖多个行业，点击模板，即可加载数据，只需简单配置，就可快速准确获取数据，满足各种采集需求.

通过自研的智能识别算法，可以自动识别列表数据识别分页，准确率达到95%，可以深入采集多级页面，快速准确的获取数据。

智能识别数据，小白神器

智能模式：基于人工智能算法，只需输入网址就能智能识别列表数据、表格数据和分页按钮，不需要配置任何采集规则，一键采集。

自动识别：列表、表格、链接、图片、价格等

流程图模式：只需根据软件提示在页面中进行点击操作，完全符合人为浏览网页的思维方式，简单几步即可生成复杂的采集规则，结合智能识别算法，任何网页的数据都能轻松采集。

可模拟操作： 输入文本、点击、移动鼠标、下拉框、滚动页面、等待加载、循环操作和判断条件等。

智能分析，可视化界面,无需学习编程，点击式界面，自动生成采集脚本，可以采集互联网99%的网站。

灵猫万能网页数据采集器

通过本课程的学习，可以了解架构技术的发展趋势，掌握最新的行业数据架构设计技术。通过本课程学习，可以更全方面的了解数据库与大数据架构优化等技能。

本课程重点介绍数据库和大数据架构设计与优化技术，学员需要掌握数据库原理、数据库自身的体系结果，方能更好的进行本课程学习。

架构作为技术与业务的融合剂，好的架构可以更好的支持业务对技术的需求，本课程重点围绕数据库架构设计特点，针对过往架构的对比分析，给学员更加直接的感受；更多的行业成功架构案例的分享，对大家学习掌握数据架构起到更好的借鉴作用。

一、百度数据库架构演变与设计

主题介绍：百度数据库架构经历了从分散式-》集中式-》分布式的过程，DBA不仅在过往的阶段做了很多工作，而且现在正对数据库架构在做很多革新。面对庞大流量、海量数据、复杂应用诸多因素，支撑数据库业务运行的数据库架构起着决定性的作用；百度数据库架构每阶段面临的问题和考虑均有不同，简洁架构的背后往往是复杂而慎重的，这里与大家主要分享百度数据库架构演变的重要阶段与设计的一些考虑要素。

讲师介绍：王龙：百度运维部DBA组经理

百度运维部DBA组经理，高级DBA，带领百度DBA团队，主要负责百度数据库运维、调优、安全、架构体系建设。百度DBA组负责百度所有数据库服务管理工作，是百度服务核心数据的提供者和保障者，是维护服务稳定的核心力量；涵盖数据库设计、评审、SQL代码REVIEW；数据库核心组件及平台的规划、设计、开发工作；使百度的数据库更稳定、更高效、更易于管理。

主题介绍：随着国内"去IOE"浪潮的起伏，Oracle在中国市场同样面临了来自技术与政策方面的双重挑战，一方面Oracle作为关系型数据库的王者，在分布式、开源开放等方面面临NoSQL等产品技术在细分市场的挑战，另一方面在政策上面临来自国产化、安全合规的挑战；在这个主题中，将和大家分享Oracle在云时代兴起之际的技术革新与挑战应对。 Oracle数据库技术的演进离不开多租户架构、内存选件、RAC集群与Exadata一体化，在这个主题中将深入剖析这些核心技术的发展脉络和Oracle的产品策略，并分析在未来，Oracle在分布式、Sharding等技术方面的必然革新。

讲师介绍：盖国强　云和恩墨创始人，ACE总监，ITPUB版主

盖国强先生是中国地区首位Oracle ACE和ACE总监，曾获评"2006年中国首届杰出数据库工程师"奖，拥有近15年的数据库实施和顾问咨询经验，对于数据库性能优化及内部技术具有深入理解。盖国强先生是中国地区最著名的Oracle技术推广者之一，他的专著《深入解析Oracle》、《循序渐进Oracle》等书籍受到Oracle技术爱好者的广泛好评，他主编撰写的《OracleDBA手记》系列作品是Oracle技术爱好者们分享和传播技术的重要书籍。2009年，盖国强先生创建了云和恩墨，致力于为中国数据库用户提供专业的数据库服务，2010年，他与Oracle ACE总监张乐奕先生共同创立ACOUG（中国Oracle用户组），持续推动Oracle技术圈的地面活动与技术交流。

三、腾讯大数据实时体系的架构和应用

主题介绍：介绍腾讯实时数据平台(TRC)实时接入，计算，存储的平台体系架构，如何利用可视化的IDE提升业务开发的效率，以及基于实时计算体系下的业务应用，例如：实时广告推荐，用户画像，监控等等

讲师介绍：张文郁　腾讯数据平台部 高级工程师

2010年加入腾讯负责分布式计算平台，集群调度的开发设计，现任数据平台部实时计算中心业务开发组组长，负责实时计算体系的建设 和业务推广，对分布式计算，流计算有丰富的应用开发经验。

四、汽车之家数据平台架构

主题介绍：从网站页面说起，用户的行为日志是怎么一层一层穿过数据平台的架构，最终展现在数据报表上的。详细介绍汽车之家如何基于大数据技术，应对业务发展的需求，构建自己的数据平台和数据仓库；分享在网站推荐和用户分析上做的一些尝试，在数据方面，遇到的一些典型问题的解决方案：1，IP地址库更新；2，evercookie & fingerprint；3，cookiemapping；4.移动deviceid的冲突和漂移及跨app共享；5，用户溯源等。

讲师介绍：高红锋　汽车之家用户智能组主管

2011年作为数据仓库架构师加入汽车之家，重构了汽车之家流量收集统计系统，从SQL Server迁移到Hadoop分布式架构，支持每日几亿流量的访问统计。负责汽车之家指数产品的研发，数据仓库平台的建设，网站推荐，用户行为分析。2014年负责开发了类似友盟的App统计SDK，支撑移动业务更精细化的运营和个性化推送。目前集群规模150台左右，支持pc和移动端流量统计，广告算法，数据仓库，指数系统，用户推荐。同时做了很多基础实践解决互联网遇到的普遍问题，如多网站cookie打通问题、IP地址库不准、cookie标识用户不准确、移动端设备id冲突和漂移等问题。

五、如何成为真正的数据架构师?

主题介绍：大数据时代下数据架构师的重要性与日俱增，企业需求量增多，但目前真正的数据架构师人才极为缺乏。数据架构师应该具备哪些能力，从事哪些工作，从属于IT的哪个部门，通过什么样的途径才能成为数据架构师，国际上数据架构师资格证有哪些等内容，将在本次演讲中予以分享。数据架构师应具备多方面的综合能力，开发人员、开发DBA、运维DBA等技术人员，通过专业的培训和学习，均有可能成为数据架构师，在本次演讲中将向希望成为数据架构师的朋友分享相关书籍、技术、及学习方法。

讲师介绍：郑保卫　恩核（北京）信息技术有限公司创始人、技术总监

工学博士，恩核（北京）信息技术有限公司创始人，担任技术总监，出版书籍《海量数据库解决方案1》，《海量数据库解决方案2》及《数据架构师教科书》正在准备中。于2013年12月被北京市朝阳区认定为"凤凰计划"海外高层次人才。参与过大量关于数据架构、数据建模、数据治理、系统性能优化等方面的项目，长期致力于数据架构及数据治理技术方面的研究和实践。

六、基于混搭存储引擎的融合型分布式数据库架构--服务型分布式计算和混搭型分布式数据存储助力大数据时代的数据宝藏挖掘

主题介绍：大数据时代，各种技术、开源软件、商业产品纷至沓来，map-reduce和CEP，Hadoop、Spark和Storm，SQL、NoSQL和NewSQL，集群、MPP和一体机，企业和互联网应用该何去何从。本主题介绍经典的分布式计算、分布式存储架构和分布式应用设计方法，以及服务型分布式计算框架如何满足各种应用需求，针对经典的分布式数据库架构进行剖析，介绍基于RDBMS，NoSQL数据库、内存数据库、文件系统等混搭存储引擎的通用分布式数据库解决方案，及这种融合型分布式数据库在社交大数据领域的应用。

讲师介绍：董健　北京博晓通科技有限公司联合创始人

南开大学计算机科学硕士，软件、通信、互联网领域拥有近二十年的丰富经验，深谙世界领先的核心平台技术，具备世界级系统的架构和设计经验，曾供职于贝尔实验室、bea、甲骨文，担任架构师、高级研发经理、产品经理等职位，带领团队开发过服务全球顶尖运营商的智能网系统，世界排名第一的交易中间件Tuxedo，世界第一个消息中间件MessageQ，WebLogic等产品，这些产品曾服务于涵盖全球500强的超过3000个企业客户，并应用于它们的核心业务应用。后创办多家公司，担任首席架构师带领团队研发出服务型分布式计算平台、通用分布式数据库、大数据整合与分析、社交媒体数据分析云平台等多款软件产品。

七、阿里海量数据迁移同步核心架构及最佳实践

主题介绍：阿里巴巴拥有全球最为庞大的数据库集群，为了让数据在各种类别的数据库之间流动起来，解决阿里双十一单元化架构中海量数据的快速异地建站（一键建站）和交易级别的异地多活问题，解决阿里业务迁移到公有云数据库问题，迫切需要一种高性能、高可用、数据一致性、还要支持各种异构数据库的迁移同步服务，由此诞生双十一新闻稿中“黑科技” ， 我有幸全程经历了这一过程，我将分享其中遇到的关键问题，如怎样确保海量数据迁移同步数据不丢？无主键表迁移同步怎么不丢数据也没有重复数据？如何实现多种异构的数据库之间的迁移？如何实现异地多活及中美秒级同步？

讲师介绍：付大超 阿里巴巴数据库团队技术专家

2012年加入阿里巴巴，目前负责DTS团队研发工作，曾负责阿里HBase的开发及维护工作，开发了阿里HBase集群高用性系统，曾先后实习及工作于IBM、Cisco、淘宝。

八、美丽说数据库架构变迁及自主研发中间件应用

主题介绍：美丽说从导购网站转型电商过程中数据库面临前所未有的挑战，主要有两方面：1、应用场景不同，导购网站的数据库量级轻，无账户，支付等系统等，流量稳定，无大促秒杀等；2、流量增加迅速，交易额million /day增长至接近billion/day 过程中犯下了一些错误，积累了一点经验，开发了一个插件，调整了一点架构；本次分享主要有两方面：1、人文，转型之路，思维意识转变，计划的制定及实施；2、技术a、架构调整与优化，包括数据库拆分，架构调整；b、中间件开发与应用，连接池，读写分离，流量控制，功能实现等；c、电商特殊场景主要是大促等容量评估以及应对方案。

讲师介绍：冯超　前美丽说数据库及中间件负责人

前美丽说数据库及中间件负责人，技术经理，6年数据库架构经验，1年创业经验，30年瞎掰经验

九、农银人寿新核心数据架构规划与当前进展

主题介绍：根据农银人寿保险股份有限公司的业务特点，结合当前主流技术和最佳行业实践，从数据的分布与存储、加工与流转、管控与应用等方面对新核心业务系统进行数据架构规划，对架构的定位与目标、原则与思路、整体规划过程进行详细阐述，其中还涉及OLTP系统、ODS、数据仓库与集市、数据交换平台的设计思路。此外，以新核心项目为背景，对现有系统实施数据治理与标准化，并在新核心建设过程中应用治理成果，从数据治理的策略原则、流程体系、方法论、组织结构、管理工具、数据现状、分阶段实施与当前进展、元数据管理、主数据管理、业务建模和数据建模过程等方面进行开创性实践和经验分享。

讲师介绍：赵华，种磊　农银人寿信息技术部副总经理，农银人寿新核心数据架构组组长

赵华，农银人寿IT部副总经理、新核心项目经理，先后在平安保险信息中心、合众人寿工作，06年加入国民人寿（农银人寿前身），有近16年寿险信息化经验，曾负责技术架构并领导过多个重大项目实施，在核心系统建设领域有突出贡献。 种磊，经济师，农银人寿IT部资深专员、新核心数据组组长。04年进入农总行软件开发中心，有8年银行信息化经验，09年参与核心银行应用设计。14年进入农银人寿，主持数据治理与标准化及新核心模型设计工作。

十、数据平台（UDP）架构设计

主题介绍：分享【友盟+】在构建数据平台的一些经验，以及在【友盟+】数据平台之上构筑的多种对外高性能数据服务架构设计。 技术点：1. 数据公司合并带来的数据和技术架构的整合带来的挑战，这里更多是经验分享；2. 我们构建的对外数据服务的低层技术架构（高并发，高可用，低延迟要求等解决方案）；

讲师介绍：张金 友盟基础数据部任技术总监　

在阿里巴巴从业6年，包括：阿里云、阿里妈妈数据技术与产品部（大中台）等在数据应用走在前沿的公司。 积累了在全域大数据以及数据周边应用，从采集、计算、挖掘、数据化运营、到广告营销的丰富实战经验。 目前在【友盟+】基础数据部任技术总监，负责构建【友盟+】的基础数据平台和数据服务平台。

十一、面向未来的数据库体系架构的思考

主题介绍：内容大纲：1. 数据存储多样性与支撑体系的思考；2. 异地多活与数据一致性的思考；3. 容器和调度在数据库的应用；4. 自动化系统的建设思路；5. 未来发展方向。

讲师介绍：张瑞 阿里巴巴集团 研究员

阿里巴巴集团数据库技术团队总负责人，研究员，2005年加入阿里巴巴，经历了阿里数据库技术的变革历程。目前，阿里数据库技术团队正在建设阿里下一代数据库技术体系，希望能够把我们的成果、踩过的坑以及面向未来思考介绍跟大家做一些深入的探讨，能够为中国数据库技术的发展出一份力。

十二、100亿数据量1万属性数据库架构设计

主题介绍：演讲提纲： 一、需求缘起：为何会有1万属性的业务需求； 二、属性扩展架构解决方案； 三、属性搜索架构解决方案； 四、100亿数据量数据库存储架构解决方案； 五、总结：一切脱离业务的架构设计都是耍流氓。

讲师介绍：沈剑 58到家技术委员会主席&高级技术总监

互联网架构技术专家，“架构师之路”公众号作者。曾任百度高级工程师，58同城高级架构师，58同城技术委员会主席，58同城C2C技术部负责人，58同城技术学院优秀讲师。现任58到家技术委员会主席，高级技术总监，负责企业，支付，营销、客户关系等多个后端业务部门。本质，技术人一枚。

十三、数据库存储虚拟化及内核架构优化

主题介绍：介绍在 K-RAC架构下的存储虚拟化技术及实现原理，同时，还会介绍近一年在数据库内核领域进行的若干技术升级以及软硬件结合领域新的进展。

讲师介绍：蒋琪 浪潮 数据库支持工程师

数据库支持工程师，多年K-DB数据库支持及内部测试经验，对数据库内核如优化器，虚拟化存储等各个模块比较了解，善于处理诊断问题。

十四、大数据实时处理架构实践

主题介绍：当今互联网早已不是蛮荒生长的时代，各大公司也在自己的领域深耕细作，伴随着市场的成熟，如何提供更好的服务、更快的数据决策，成为竞争的关键点。实时计算技术作为其中的一项关键技术，开始在业界广泛流行。如何依据自己的业务，在众多的实时计算技术中做出选择，如何处理实时计算中遇到的各种问题，保证数据的效率和正确，成为所有人都要面对的极具挑战的工作。本次分享将会从实时计算的业务要求出发，结合具体的一个基于spark streaming的实践例子，总结大数据实时处理架构设计上需要处理的几个关键问题，同时基于此对实时计算技术提出一些要求。

讲师介绍：朱健 京东商城大数据技术专家

京东广告部大数据技术专家，长期从事大数据技术的实践和研究工作，在分布式系统架构设计、开发方面有丰富的实践经验。目前负责京东广告日志系统、广告实时效果系统的研发工作。

十五、Kudu架构介绍及其在小米的应用实践

主题介绍：Kudu是Cloudera在15年9月开源的分布式数据存储引擎，其结合了Hbase和HDFS的优势，可以同时提供高效的随机访问以及数据扫描能力。Kudu支持数据的实时插入和分析，为实时的OLAP计算提供了另外一种选择。小米是Kudu在中国最早的一批用户，目前内部已经有较大规模的业务在使用，并且在不断探索新的应用场景。本次演讲将会介绍Kudu的大致技术架构，新版本的新增功能，以及未来的开发计划。同时会介绍Kudu在小米计算架构中所扮演的角色，分享一些Kudu在实际使用中的经验，希望可以促进Kudu在中国的发展和使用。

讲师介绍：张震 小米软件工程师

曾就职于老牌BI厂商MicroStrategy，15年加入小米云平台计算组，先后负责Impala，Hive，Kudu的维护和及内部需求开发。在分布式计算和存储领域有多年的积累和实战经验

十六、分布式数据库的架构与分片设计

主题介绍：1、介绍行业信息化的现状，阐述为何企业需要分布式数据库和私有云数据库。 2、介绍不同历史时期背景而产生的MySQL数据库的架构，讲述架构演变的过程和背后故事。 3、 企业对私有云数据库的诉求和技术架构。 4、企业关注私有云数据库哪些核心功能以及部分核心功能点的技术原理讲解。 5、分享个人对行业调研、观察和分析的信息而得的出国内私有云数据库的未来发展趋势。

讲师介绍：金官丁 上海热璞网络科技有限公司 创始人兼CTO

主要负责热璞科技的私有云数据库产品规划、架构设计和咨询解决方案。 拥有丰富的千万以上日活跃会员的数据架构设计及直接研发管理经验，传统行业数十个超大型业务系统的去IOE化和分布式数据架构设计，多次主设计数十亿级别数据服务的高并发、高性能、高可用分布式数据库架构。 曾就职于游戏米果、麦肯光明、阿里巴巴、五分钟网络，从事过产品研发、咨询服务和 技术团队管理等；在阿里巴巴工作期间，担任数据库专家一职，负责开源分布式数据库技术 架构探索研究实践（注：设计过广泛用于阿里巴巴内部和行业的分布式数据库中间件产品， 且同行业多数企业模仿此产品路线），后称“去IOE”，应用于整个集团及借助探索的实战经 验和成果，广泛应用于后组建的阿里云；在五分钟网络工作期间，担任技术副总监，负责开 心农场、小小战争等游戏研发团队，设计研发社交游戏引擎（含分布式数据库产品）、社交 游戏运营平台等。

更多详情，请转向我的Github仓库：

欢迎来做客，欢迎star~

在本文将讨论数据库原理和MySQL核心知识，MySQL性能优化等，包含 “MySQL基础” 和 “高性能MySQL实践” 两部分。

• 《高性能MySQL》第三版
• 部分参考：，特别鸣谢作者 @CyC2018

• 【慕课网】MySQL性能管理及架构设计
• 【龙果学院】MySQL大型分布式集群

第一部分：MySQL基础

MySQL的多存储引擎架构

这里先有个整体的MySQL Server的整体概念，详情转向：

（3）在事务1中，Mary 再次读取自己的工资时，工资变为了2000

在一个事务中前后两次读取的结果并不致，导致了不可重复读。

　　如果只有在修改事务完全提交之后才可以读取数据，则可以避免该问题。把数据库的事务隔离级别调整到REPEATABLE_READ

　　T2 读取一个数据，T1 对该数据做了修改。如果 T2 再次读取这个数据，此时读取的结果和第一次读取的结果不同。

事务1再次读取所有工资为 1000的 员工（共读取到了 11 条记录，这就像产生了幻读）

　　如果在操作事务完成数据处理之前，任何其他事务都不可以添加新数据，则可避免该问题。把数据库的事务隔离级别调整到 SERIALIZABLE_READ

　　T1 读取某个范围的数据，T2 在这个范围内插入新的数据，T1 再次读取这个范围的数据，此时读取的结果和和第一次读取的结果不同。

　　所有事务一个接着一个的执行，这样可以避免幻读 (phantom read)，对于基于锁来实现并发控制的数据库来说，串行化要求在执行范围查询的时候，需要获取范围锁，如果不是基于锁实现并发控制的数据库，则检查到有违反串行操作的事务时，需回滚该事务。

　　所有被 Select 获取的数据都不能被修改，这样就可以避免一个事务前后读取不一致的情况。但是没有办法控制幻读，因为这个时候其他事务不能更改所选的数据，但是可以增加数据，因为强恶意事务没有范围锁。

　　被读取的数据可以被其他事务修改，这样可能导致不可重复读。也就是说，事务读取的时候获取读锁，但是在读完之后立即释放(不需要等事务结束)，而写锁则是事务提交之后才释放，释放读锁之后，就可能被其他事务修改数据。该等级也是 SQL Server 默认的隔离等级。

　　最低的隔离等级，允许其他事务看到没有提交的数据，会导致脏读。

• 四个级别逐渐增强，每个级别解决一个问题，每个级别解决一个问题，事务级别遇到，性能越差，大多数环境(Read committed 就可以用了)

隔离级别脏读不可重复读幻影读未提交读√√√提交读×√√可重复读××√可串行化×××

　　对于初学者来说我们通常不关注存储引擎，但是 MySQL 提供了多个存储引擎，包括处理事务安全表的引擎和处理非事务安全表的引擎。在 MySQL 中，不需要在整个服务器中使用同一种存储引擎，针对具体的要求，可以对每一个表使用不同的存储引擎。

　　MySQL 中的数据用各种不同的技术存储在文件（或者内存）中。这些技术中的每一种技术都使用不同的存储机制、索引技巧、锁定水平并且最终提供广泛的不同的功能和能力。通过选择不同的技术，你能够获得额外的速度或者功能，从而改善你的应用的整体功能。存储引擎说白了就是如何存储数据、如何为存储的数据建立索引和如何更新、查询数据等技术的实现方法。

　　例如，如果你在研究大量的临时数据，你也许需要使用内存存储引擎。内存存储引擎能够在内存中存储所有的表格数据。又或者，你也许需要一个支持事务处理的数据库（以确保事务处理不成功时数据的回退能力）。

在MySQL中有很多存储引擎，每种存储引擎大相径庭，那么又改如何选择呢？

　　不同存储引起都有各自的特点，为适应不同的需求，需要选择不同的存储引擎，所以首先考虑这些存储引擎各自的功能和兼容。

MySQL 5.5版本之前的默认存储引擎，在 5.0 以前最大表存储空间最大 4G，5.0 以后最大 256TB。

Myisam 存储引擎由 .myd（数据）和 .myi（索引文件）组成，.frm文件存储表结构（所以存储引擎都有）

• 并发性和锁级别 （对于读写混合的操作不好，为表级锁，写入和读互斥）
• Myisam 表支持的索引类型（全文索引）
• Myisam 支持表压缩（压缩后，此表为只读，不可以写入。使用myisampack压缩）

• 只读类应用（插入不频繁，查询非常频繁）
• 空间类应用（唯一支持空间函数的引擎）

MySQL 5.5 及之后版本的默认存储引擎

• Innodb为事务性存储引擎
• 完全支持事物的 ACID 特性
• Redo log （实现事务的持久性） 和 Undo log（为了实现事务的原子性，存储未完成事务log，用于回滚）
• 行级锁可以最大程度的支持并发
• 行级锁是由存储引擎层实现的

• 可靠性要求比较高，或者要求事务
• 表更新和查询都相当的频繁，并且行锁定的机会比较大的情况。

• 数据以文本方式存储在文件中
• .csv文件存储表内容
• .csm文件存储表的元数据，如表状态和数据量

• 以 CSV 格式进行数据存储
• 所有列必须都是不能为 NULL
• 可以对数据文件直接编辑（其他引擎是二进制存储，不可编辑）

• 以 zlib 对表数据进行压缩，磁盘 I/O 更少
• 数据存储在ARZ为后缀的文件中（表文件为 a.arz，a.frm）
• 只允许在自增ID列上加索引

• 也称为 HEAP 存储引擎，所以数据保存在内存中（数据库重启后会导致数据丢失）
• 支持 HASH 索引（等值查找应选择 HASH）和 BTree 索引（范围查找应选择）
• Memory 存储使用表级锁（性能可能不如 innodb）

• 用于查找或是映射表，例如右边和地区的对应表
• 用于保存数据分析中产生的中间表
• 用于缓存周期性聚合数据的结果表

注意： Memory 数据易丢失，所以要求数据可再生

• 提供了访问远程 MySQL 服务器上表的方法
• 本地不存储数据，数据全部放在远程服务器上

默认是禁止的。如果需要启用，需要在启动时增加Federated参数

问：独立表空间和系统表空间应该如何抉择

• 系统表空间：无法简单的收缩大小（这很恐怖，会导致 ibdata1 一直增大，即使删除了数据也不会变小）
• 独立表空间：可以通过 optimize table 命令收缩系统文件
• 系统表空间：会产生I/O瓶颈（因为只有一个文件）
• 独立表空间：可以向多个文件刷新数据

总结 强烈建议：对Innodb引擎使用独立表空间（mysql5.6版本以后默认是独立表空间）

系统表转移为独立表的步骤（非常繁琐）

• 使用 mysqldump 导出所有数据库表数据
• 停止 mysql 服务，修改参数，并且删除Innodb相关文件

重要一点： 不要混合使用存储引擎 强烈推荐： Innodb

• MyISAM 是非事务安全型的，而 InnoDB 是事务安全型的。
• MyISAM 锁的粒度是表级，而 InnoDB 支持行级锁定。
• MyISAM 支持全文类型索引，而 InnoDB 不支持全文索引。
• MyISAM 相对简单，所以在效率上要优于 InnoDB，小型应用可以考虑使用 MyISAM。
• MyISAM 表是保存成文件的形式，在跨平台的数据转移中使用 MyISAM 存储会省去不少的麻烦。

• MyISAM 管理非事务表。它提供高速存储和检索，以及全文搜索能力。如果应用中需要执行大量的 SELECT 查询，那么 MyISAM 是更好的选择。
• InnoDB 用于事务处理应用程序，具有众多特性，包括 ACID 事务支持。如果应用中需要执行大量的 INSERT 或 UPDATE 操作，则应该使用 InnoDB，这样可以提高多用户并发操作的性能。

问：为什么不建议 InnoDB 使用亿级大表

仅作拓展延伸，详情请转向：

INT(11) 中的数字只是规定了交互工具显示字符的个数，对于存储和计算来说是没有意义的。

FLOAT 和 DOUBLE 为浮点类型，DECIMAL 为高精度小数类型。CPU 原生支持浮点运算，但是不支持 DECIMAl 类型的计算，因此 DECIMAL 的计算比浮点类型需要更高的代价。

主要有 CHAR 和 VARCHAR 两种类型，一种是定长的，一种是变长的。

VARCHAR 这种变长类型能够节省空间，因为只需要存储必要的内容。但是在执行 UPDATE 时可能会使行变得比原来长，当超出一个页所能容纳的大小时，就要执行额外的操作。MyISAM 会将行拆成不同的片段存储，而 InnoDB 则需要分裂页来使行放进页内。

VARCHAR 会保留字符串末尾的空格，而 CHAR 会删除。

能够保存从 1001 年到 9999 年的日期和时间，精度为秒，使用 8 字节的存储空间。

默认情况下，MySQL 以一种可排序的、无歧义的格式显示 DATATIME 值，例如“ 22:37:08”，这是 ANSI 标准定义的日期和时间表示方法。

和 UNIX 时间戳相同，保存从 1970 年 1 月 1 日午夜（格林威治时间）以来的秒数，使用 4 个字节，只能表示从 1970 年 到 2038 年。

它和时区有关，也就是说一个时间戳在不同的时区所代表的具体时间是不同的。

默认情况下，如果插入时没有指定 TIMESTAMP 列的值，会将这个值设置为当前时间。

索引能够轻易将查询性能提升几个数量级。

1. 对于非常小的表、大部分情况下简单的全表扫描比建立索引更高效。
2. 对于中到大型的表，索引就非常有效。
3. 但是对于特大型的表，建立和维护索引的代价将会随之增长。这种情况下，需要用到一种技术可以直接区分出需要查询的一组数据，而不是一条记录一条记录地匹配，例如可以使用分区技术。

索引是在存储引擎层实现的，而不是在服务器层实现的，所以不同存储引擎具有不同的索引类型和实现。

定义一条数据记录为一个二元组 [key, data]，B-Tree 是满足下列条件的数据结构：

• 所有叶节点具有相同的深度，也就是说 B-Tree 是平衡的；
• 一个节点中的 key 从左到右非递减排列；

查找算法：首先在根节点进行二分查找，如果找到则返回对应节点的 data，否则在相应区间的指针指向的节点递归进行查找。

由于插入删除新的数据记录会破坏 B-Tree 的性质，因此在插入删除时，需要对树进行一个分裂、合并、旋转等操作以保持 B-Tree 性质。

• 每个节点的指针上限为 2d 而不是 2d+1（d 为节点的出度）；
• 内节点不存储 data，只存储 key；

一般在数据库系统或文件系统中使用的 B+Tree 结构都在经典 B+Tree 基础上进行了优化，在叶子节点增加了顺序访问指针，做这个优化的目的是为了提高区间访问的性能。

红黑树等平衡树也可以用来实现索引，但是文件系统及数据库系统普遍采用 B Tree 作为索引结构，主要有以下两个原因：

平衡树检索数据的时间复杂度等于树高 h，而树高大致为 O(h)=O(logdN)，其中 d 为每个节点的出度。

红黑树的出度为 2，而 B Tree 的出度一般都非常大。红黑树的树高 h 很明显比 B Tree 大非常多，因此检索的次数也就更多。

B+Tree 相比于 B-Tree 更适合外存索引，因为 B+Tree 内节点去掉了 data 域，因此可以拥有更大的出度，检索效率会更高。

（二）利用计算机预读特性

为了减少磁盘 I/O，磁盘往往不是严格按需读取，而是每次都会预读。这样做的理论依据是计算机科学中著名的局部性原理：当一个数据被用到时，其附近的数据也通常会马上被使用。预读过程中，磁盘进行顺序读取，顺序读取不需要进行磁盘寻道，并且只需要很短的旋转时间，因此速度会非常快。

操作系统一般将内存和磁盘分割成固态大小的块，每一块称为一页，内存与磁盘以页为单位交换数据。数据库系统将索引的一个节点的大小设置为页的大小，使得一次 I/O 就能完全载入一个节点，并且可以利用预读特性，相邻的节点也能够被预先载入。

B+Tree 索引是大多数 MySQL 存储引擎的默认索引类型。

因为不再需要进行全表扫描，只需要对树进行搜索即可，因此查找速度快很多。除了用于查找，还可以用于排序和分组。

可以指定多个列作为索引列，多个索引列共同组成键。

B+Tree 索引适用于全键值、键值范围和键前缀查找，其中键前缀查找只适用于最左前缀查找。

如果不是按照索引列的顺序进行查找，则无法使用索引。

主索引的叶子节点 data 域记录着完整的数据记录，这种索引方式被称为聚簇索引。因为无法把数据行存放在两个不同的地方，所以一个表只能有一个聚簇索引。

辅助索引的叶子节点的 data 域记录着主键的值，因此在使用辅助索引进行查找时，需要先查找到主键值，然后再到主索引中进行查找。

InnoDB 引擎有一个特殊的功能叫 “自适应哈希索引”，当某个索引值被使用的非常频繁时，会在 B+Tree 索引之上再创建一个哈希索引，这样就让 B+Tree 索引具有哈希索引的一些优点，比如快速的哈希查找。

哈希索引能以 O(1) 时间进行查找，但是失去了有序性，它具有以下限制：

• 只支持精确查找，无法用于部分查找和范围查找；

MyISAM 存储引擎支持全文索引，用于查找文本中的关键词，而不是直接比较是否相等。查找条件使用 MATCH AGAINST，而不是普通的 WHERE。

全文索引一般使用倒排索引实现，它记录着关键词到其所在文档的映射。

空间数据索引（R-Tree）

MyISAM 存储引擎支持空间数据索引，可以用于地理数据存储。空间数据索引会从所有维度来索引数据，可以有效地使用任意维度来进行组合查询。

必须使用 GIS 相关的函数来维护数据。

• 可以加快数据库的检索速度
• 降低数据库插入、修改、删除等维护的速度
• 只能创建在表上，不能创建到视图上
• 既可以直接创建又可以间接创建
• 可以在优化隐藏中使用索引
• 使用查询处理器执行SQL语句，在一个表上，一次只能使用一个索引

• 创建唯一性索引，保证数据库表中每一行数据的唯一性
• 大大加快数据的检索速度，这是创建索引的最主要的原因
• 加速数据库表之间的连接，特别是在实现数据的参考完整性方面特别有意义
• 在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间
• 通过使用索引，可以在查询中使用优化隐藏器，提高系统的性能

• 创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加
• 索引需要占用物理空间，除了数据表占用数据空间之外，每一个索引还要占一定的物理空间，如果建立聚簇索引，那么需要的空间就会更大
• 当对表中的数据进行增加、删除和修改的时候，索引也需要维护，降低数据维护的速度

• 如果条件中有or，即使其中有条件带索引也不会使用 (这就是问什么尽量少使用or的原因)
• 对于多列索引，不是使用的第一部分，则不会使用索引
• like查询是以%开头
• 如果列类型是字符串，那一定要在条件中使用引号引起来，否则不会使用索引
• 如果MySQL估计使用全表扫秒比使用索引快，则不适用索引。

8. 在什么情况下适合建立索引

• 在union等集合操作的结果集字段上，建立索引。其建立索引的目的同上。
• 为经常用作查询选择 where 后的字段，建立索引。
• 在经常用作表连接 join 的属性上，建立索引。
• 考虑使用索引覆盖。对数据很少被更新的表，如果用户经常只查询其中的几个字段，可以考虑在这几个字段上建立索引，从而将表的扫描改变为索引的扫描。

两个或更多个列上的索引被称作联合索引，联合索引又叫复合索引。对于复合索引：Mysql 从左到右的使用索引中的字段，一个查询可以只使用索引中的一部份，但只能是最左侧部分。

例如索引是key index (a,b,c)，可以支持[a]、[a,b]、[a,b,c] 3种组合进行查找，但不支 [b,c] 进行查找。当最左侧字段是常量引用时，索引就十分有效。

1. 需要加索引的字段，要在 where 条件中
2. 数据量少的字段不需要加索引
3. 如果 where 条件中是OR关系，加索引不起作用

其中 table_name 是要增加索引的表名，column_list 指出对哪些列进行索引，多列时各列之间用逗号分隔。索引名 index_name 可选，缺省时，MySQL将根据第一个索引列赋一个名称。另外，ALTER TABLE 允许在单个语句中更改多个表，因此可以在同时创建多个索引。

在创建索引时，可以规定索引能否包含重复值。如果不包含，则索引应该创建为 PRIMARY KEY 或 UNIQUE 索引。对于单列惟一性索引，这保证单列不包含重复的值。对于多列惟一性索引，保证多个值的组合不重复。 PRIMARY KEY 索引和 UNIQUE 索引非常类似。

第3条语句只在删除 PRIMARY KEY 索引时使用，因为一个表只可能有一个 PRIMARY KEY 索引，因此不需要指定索引名。如果没有创建 PRIMARY KEY 索引，但表具有一个或多个 UNIQUE 索引，则 MySQL 将删除第一个 UNIQUE 索引。

如果从表中删除了某列，则索引会受到影响。对于多列组合的索引，如果删除其中的某列，则该列也会从索引中删除。如果删除组成索引的所有列，则整个索引将被删除。

6. 什么情况下使用索引

1. 为了快速查找匹配WHERE条件的行。
2. 为了从考虑的条件中消除行。
3. 如果表有一个multiple-column索引，任何一个索引的最左前缀可以通过使用优化器来查找行。
4. 查询中与其它表关联的字，字段常常建立了外键关系
5. 查询中统计或分组统计的字段

10. 聚集索引与非聚集索引

11. 数据库中的分页查询语句怎么写？【阿里面经】

• LIMIT 接受一个或两个数字参数。参数必须是一个整数常量。如果给定两个参数，第一个参数指定第一个返回记录行的偏移量，第二个参数指定返回记录行的最大数目。初始记录行的偏移量是 0(而不是 1)

12. 常用的数据库有哪些？Redis用过吗？【阿里面经】

• 常用的数据库有哪些？Redis用过吗？
  • Redis 是一个速度非常快的非关系型数据库，他可以存储键(key)与5种不同类型的值（value）之间的映射，可以将存储在内存中的键值对数据持久化到硬盘中。
  • 两者都可用于存储键值映射，彼此性能也相差无几
  • Redis 能够自动以两种不同的方式将数据写入硬盘
  • Redis 除了能存储普通的字符串键之外，还可以存储其他4种数据结构，memcached 只能存储字符串键
  • Redis 既能用作主数据库，由可以作为其他存储系统的辅助数据库
  • 缓存、任务队列、应用排行榜、网站访问统计、数据过期处理、分布式集群架构中的session分离

• 海量数据的高效存储和访问

• STRING：可以是字符串、整数或者浮点数
• LIST：一个链表，链表上的每个节点都包含了一个字符串
• SET：包含字符串的无序收集器（unordered collection），并且被包含的每个字符串都是独一无二、各不相同的
• HAST：包含键值对的无序散列表
• ZSET：字符串成员（member）与浮点数分值（score）之间的有序映射，元素的排列顺序由分值的大小决定

注：更多 Redis 相关内容将在

简单来说，数据的切分就是通过某种特定的条件，将我们存放在同一个数据库中的数据分散存放到多个数据库（主机）中，以达到分散单台设备负载的效果，即分库分表。

数据的切分根据其切分规则的类型，可以分为如下两种切分模式。

• 垂直（纵向）切分：把单一的表拆分成多个表，并分散到不同的数据库（主机）上。
• 水平（横向）切分：根据表中数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库（主机）上。

垂直切分是将一张表按列切分成多个表，通常是按照列的关系密集程度进行切分，也可以利用垂直切分将经常被使用的列和不经常被使用的列切分到不同的表中。

在数据库的层面使用垂直切分将按数据库中表的密集程度部署到不同的库中，例如将原来的电商数据库垂直切分成商品数据库 payDB、用户数据库 userBD 等。

• 拆分后业务清晰，拆分规则明确
• 系统之间进行整合或扩展很容易
• 按照成本、应用的等级、应用的类型等将表放到不同的机器上，便于管理
• 便于实现动静分离、冷热分离的数据库表的设计模式

• 部分业务表无法关联（Join），只能通过接口方式解决，提高了系统的复杂度
• 受每种业务的不同限制，存在单库性能瓶颈，不易进行数据扩展和提升性能

水平切分又称为 Sharding，它是将同一个表中的记录拆分到多个结构相同的表中。

当一个表的数据不断增多时，Sharding 是必然的选择，它可以将数据分布到集群的不同节点上，从而缓存单个数据库的压力。

• 单库单表的数据保持在一定的量级，有助于性能的提高
• 切分的表的结构相同，应用层改造较少，只需要增加路由规则即可
• 提高了系统的稳定性和负载能力

• 切分后，数据是分散的，很难利用数据库的Join操作，跨库Join性能较差
• 分片事务的一致性难以解决
• 数据扩容的难度和维护量极大

垂直切分和水平切分的共同点

• 存在跨节点Join的问题
• 存在跨节点合并排序、分页的问题
• 存在多数据源管理的问题

• 范围：可以是 ID 范围也可以是时间范围
  
• 比如每台服务器计划存放一个亿的数据,先将数据写入服务器A.一旦服务器A写满,则将数据写入服务器B,以此类推. 这种方式的好处是扩展方便.数据在各个服务器上分布均匀.

• 映射表：使用单独的一个数据库来存储映射关系

使用分布式事务来解决，比如 XA 接口。

可以将原来的 JOIN 查询分解成多个单表查询，然后在用户程序中进行 JOIN。

• 使用全局唯一 ID：GUID。
• 为每个分片指定一个 ID 范围。

15. 主从复制与读写分离

主要涉及三个线程：binlog 线程、I/O 线程和 SQL 线程。

• binlog 线程 ：负责将主服务器上的数据更改写入二进制文件（binlog）中。
• I/O 线程 ：负责从主服务器上读取二进制日志文件，并写入从服务器的中继日志中。
• SQL 线程 ：负责读取中继日志并重放其中的 SQL 语句。

主服务器用来处理写操作以及实时性要求比较高的读操作，而从服务器用来处理读操作。

读写分离常用代理方式来实现，代理服务器接收应用层传来的读写请求，然后决定转发到哪个服务器。

MySQL 读写分离能提高性能的原因在于：

• 主从服务器负责各自的读和写，极大程度缓解了锁的争用；
• 从服务器可以配置 MyISAM 引擎，提升查询性能以及节约系统开销；
• 增加冗余，提高可用性。

Explain 用来分析 SELECT 查询语句，开发人员可以通过分析 Explain 结果来优化查询语句。

• select_type : 查询类型，有简单查询、联合查询、子查询等

1. 减少请求的数据量

使用 WHERE 语句进行查询过滤，有时候也需要使用 LIMIT 语句来限制返回的数据。

（三）缓存重复查询的数据

使用缓存可以避免在数据库中进行查询，特别要查询的数据经常被重复查询，缓存可以带来的查询性能提升将会是非常明显的。

2. 减少服务器端扫描的行数

最有效的方式是使用索引来覆盖查询。

一个大查询如果一次性执行的话，可能一次锁住很多数据、占满整个事务日志、耗尽系统资源、阻塞很多小的但重要的查询。

将一个大连接查询（JOIN）分解成对每一个表进行一次单表查询，然后将结果在应用程序中进行关联，这样做的好处有：

• 让缓存更高效。对于连接查询，如果其中一个表发生变化，那么整个查询缓存就无法使用。而分解后的多个查询，即使其中一个表发生变化，对其它表的查询缓存依然可以使用。
• 分解成多个单表查询，这些单表查询的缓存结果更可能被其它查询使用到，从而减少冗余记录的查询。
• 在应用层进行连接，可以更容易对数据库进行拆分，从而更容易做到高性能和可扩展。
• 查询本身效率也可能会有所提升。例如下面的例子中，使用 IN() 代替连接查询，可以让 MySQL 按照 ID 顺序进行查询，这可能比随机的连接要更高效。

第二部分：高性能MySQL实践

1. 如何解决秒杀的性能问题和超卖的讨论

抢订单环节一般会带来2个问题：

　　比较火热的秒杀在线人数都是10w起的，如此之高的在线人数对于网站架构从前到后都是一种考验。

　　任何商品都会有数量上限，如何避免成功下订单买到商品的人数不超过商品数量的上限，这是每个抢购活动都要面临的难题。

　　将存库MySQL前移到Redis中，所有的写操作放到内存中，由于Redis中不存在锁故不会出现互相等待，并且由于Redis的写性能和读性能都远高于MySQL，这就解决了高并发下的性能问题。然后通过队列等异步手段，将变化的数据异步写入到DB中。

　　优点：解决性能问题

　　缺点：没有解决超卖问题，同时由于异步写入DB，存在某一时刻DB和Redis中数据不一致的风险。

引入队列，然后将所有写DB操作在单队列中排队，完全串行处理。当达到库存阀值的时候就不在消费队列，并关闭购买功能。这就解决了超卖问题。

　　优点：解决超卖问题，略微提升性能。

　　缺点：性能受限于队列处理机处理性能和DB的写入性能中最短的那个，另外多商品同时抢购的时候需要准备多条队列。

　　**将提交操作变成两段式，先申请后确认。然后利用Redis的原子自增操作（相比较MySQL的自增来说没有空洞），同时利用Redis的事务特性来发号，保证拿到小于等于库存阀值的号的人都可以成功提交订单。**然后数据异步更新到DB中。

　　优点：解决超卖问题，库存读写都在内存中，故同时解决性能问题。

　　缺点：由于异步写入DB，可能存在数据不一致。另可能存在少买，也就是如果拿到号的人不真正下订单，可能库存减为0，但是订单数并没有达到库存阀值。

2. 数据库主从不一致，怎么解

数据库主库和从库不一致，常见有这么几种优化方案：

（1）业务可以接受，系统不优化

（2）强制读主，高可用主库，用缓存提高读性能

（3）在cache里记录哪些记录发生过写请求，来路由读主还是读从