Mysql

先看mysql的架构图能够说mysql的次要架构分为server层和存储引擎层。 连接器：次要负责用户登录数据库，进行用户的身份认证，包含校验账户明码，权限等操作，如果用户账户明码已通过，连接器会到权限表中查问该用户的所有权限，之后在这个连贯里的权限逻辑判断都是会依赖此时读取到的权限数据，也就是说，后续只有这个连接不断开，即时管理员批改了该用户的权限，该用户也是不受影响的。 查问缓存连贯建设后，执行查问语句的时候，会先查问缓存，Mysql会先校验这个sql是否执行过，以Key-Value的模式缓存在内存中，Key是查问预计，Value是后果集。如果缓存key被命中，就会间接返回给客户端，如果没有命中，就会执行后续的操作，实现后也会把后果缓存起来，不便下一次调用。当然在真正执行缓存查问的时候还是会校验用户的权限，是否有该表的查问条件。Mysql 8.0 版本后删除了缓存的性能，官网也是认为该性能在理论的利用场景比拟少，所以罗唆间接删掉了。 分析器mysql 没有命中缓存，那么就会进入分析器，分析器次要是用来剖析SQL语句是来干嘛的，分析器也会分为几步：第一步，词法剖析，一条SQL语句有多个字符串组成，首先要提取关键字，比方select，提出查问的表，提出字段名，提出查问条件等等。做完这些操作后，就会进入第二步。 第二步，语法分析，次要就是判断你输出的sql是否正确，是否合乎mysql的语法。 优化器优化器的作用就是它认为的最优的执行计划去执行（尽管有时候也不是最优），比方多个索引的时候该如何抉择索引，多表查问的时候如何抉择关联程序等。 执行器抉择了执行计划后，mysql就筹备开始执行了，首先执行前会校验该用户有没有权限，如果没有权限，就会返回错误信息，如果有权限，就会去调用引擎的接口，返回接口执行的后果。

一、前言随着业务倒退，对数据库的并发性能要求也越来越高，不仅要做到高并发还须要在保障数据安全，那么明天咱们聊一聊 MySQL 在高并发下事务、MVCC、锁机制是如何在高并发状况下保护数据的平安。 二、事务 ACID为什么须要事务：事务是为了保障用户的数据操作对数据是平安的。比方咱们的银行卡余额，咱们心愿对它的操作是稳固精确的，而且相对平安。ACID：事务的四大个性原子性、一致性、隔离性、持久性。原子性：原子性是指一个事务要么全副执行，要么齐全不执行。次要是由 innodb 引擎中的 undo 回滚日志来保护。隔离性：事务在操作过程中不会受到其它事务操作的影响。次要由事务的隔离级别和锁机制独特保护。持久性：事务操作的后果是具体持久性的，艰深来讲就是提交事务后会长久化存储(落盘)。次要是由 redo log 来保护。一致性：事务在开始和完结时，数据始终保持统一。由原子性、隔离性、持久性独特保护。三、多版本并发管制 MVCC*介绍：数据库的外围方向就是高并发，MySQL 通过并发控制技术来保护高并发的环境下数据的一致性和数据安全。MySQL 并发管制有两种技术计划锁机制(Locking) 和 多版本并发管制 (MVCC)。 锁机制：通过锁机制能够保护数据的一致性，然而整体业务场景大多是读-读、读-写、写-写，三类并发场景，看似容易交融到业务场景后也比较复杂。通过锁机制次要能够帮忙咱们解决写-写 和 读-读 场景下的并发平安问题 则 MVCC 次要帮忙解决 读-写 问题。MVCC：多版本并发管制，偏重优化读-写业务的高并发环境。能够解决写操作时梗塞读操作的并发问题。一致性非锁定读：指 innodb 引擎通过多版本并发管制的形式来读取，以后执行工夫数据库中的行数据。读取正在进行 update 或 delete 操作的行，不会期待锁开释，而是会读取该行的快照数据。快照就是指该行之前的版本数据，次要靠 undo 日志来实现，而 undo 是用于数据库回滚，因而快照读自身是没有开销的。后盾 Purge 线程也会主动清理一些不须要的 undo 数据。MVCC 两类读操作：分为两类读状况 快照读(Snapshot Read) 和 以后读(Current Read) 快照读是读取数据的可见版本而以后读则是读取以后数据的最新版本须要加锁从而保障其它事务不会批改以后数据。MVCC 实现策略：咱们在设计表过程中通过不会间接删除数据而是设定一个字段来标记，从实现逻辑意义上的删除。MVCC 的实现形式也与此相似。这种数据管理形式叫数据生命周期治理，其中两个指标就是标记数据的变动 和 标记数据可用状态。MVCC 下的 DML过程演示：Insert：进行 insert 操作，事务 id 假如为 1 Update：MVCC 会先将以后记录标记为已删除在 delete version 字段下设置版本号(原来为空)，而后新增一行数据，写入相应的版本号，此时为新版本号为 2 和上一条数据的 delete version 统一，比方将 name 批改为 fantasy，如下表： ...

作者：xuty本文起源：原创投稿*爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。一、景象某我的项目反馈系统十分卡，登陆 MySQL 后发现大量 SQL 处于 Opening tables 状态，断断续续，一会好一会又呈现，比拟离奇。 之前遇到过相似的问题景象，是因为 MySQL 开启了 AHI（自适应哈希索引）后如果 DROP 或 TRUNCATE 一张大表，MySQL 会同时删除 buffer pool 中对应表上的 AHI，这个过程需会持有一把数据字典锁（十分重的锁），导致其余用户线程因为无奈获数据字典锁而处于 Opening tables 状态。 然而这里查看过所有的会话 SQL，并没有发现有 DROP 或者 TRUNCATE 语句，所以应该不是上述的这种问题，而是其余的起因导致了相似的景象。 值得狐疑的是，这台 MySQL 服务器的磁盘写入性能很差，会不会是因为磁盘写入太差导致这个景象？ 因为一时间没法排查出具体起因，所以针对 MySQL 过程打了个快照，不便预先具体排查。 二、剖析栈帧用 pt-pmp 工具解决下快照后，内容比拟多，这里只显示一些比拟重要的堆栈： 1402 pthread_cond_wait,wait(os0event.cc:165),os_event::wait_low(os0event.cc:165),sync_array_wait_event(sync0arr.cc:475),TTASEventMutex::wait(ut0mutex.ic:89),spin_and_try_lock(ib0mutex.h:850),enter(ib0mutex.h:850),PolicyMutex<TTASEventMutex<GenericPolicy>(ib0mutex.h:850),dict_table_open_on_name(dict0dict.cc:1238),ha_innobase::open_dict_table(ha_innodb.cc:6250),ha_innobase::open(ha_innodb.cc:5888),handler::ha_open(handler.cc:2759),open_table_from_share(table.cc:3353),open_table(sql_base.cc:3559),open_and_process_table(sql_base.cc:5145),open_tables(sql_base.cc:5145),open_tables_for_query(sql_base.cc:6531),execute_sqlcom_select(sql_parse.cc:5127),mysql_execute_command(sql_parse.cc:2792),mysql_parse(sql_parse.cc:5582),dispatch_command(sql_parse.cc:1458),do_command(sql_parse.cc:999),handle_connection(connection_handler_per_thread.cc:300),pfs_spawn_thread(pfs.cc:2190),start_thread(libpthread.so.0),clone(libc.so.6)36 nanosleep(libpthread.so.0),os_thread_sleep(os0thread.cc:279),buf_flush_wait_flushed(buf0flu.cc:2074),log_preflush_pool_modified_pages(log0log.cc:1531),log_checkpoint_margin(log0log.cc:1973),log_check_margins(log0log.cc:1973),log_free_check(log0log.ic:491),row_ins_sec_index_entry(log0log.ic:491),row_ins_index_entry(row0ins.cc:3460),row_ins_index_entry_step(row0ins.cc:3460),row_ins(row0ins.cc:3460),row_ins_step(row0ins.cc:3460),row_insert_for_mysql_using_ins_graph(row0mysql.cc:1738),ha_innobase::write_row(ha_innodb.cc:7566),handler::ha_write_row(handler.cc:7991),write_record(sql_insert.cc:1873),Sql_cmd_insert::mysql_insert(sql_insert.cc:769),Sql_cmd_insert::execute(sql_insert.cc:3105),mysql_execute_command(sql_parse.cc:3566),mysql_parse(sql_parse.cc:5582),dispatch_command(sql_parse.cc:1458),do_command(sql_parse.cc:999),handle_connection(connection_handler_per_thread.cc:300),pfs_spawn_thread(pfs.cc:2190),start_thread(libpthread.so.0),clone(libc.so.6)1 pthread_cond_wait,wait(os0event.cc:165),os_event::wait_low(os0event.cc:165),buf_dblwr_flush_buffered_writes(buf0dblwr.cc:979),buf_dblwr_add_to_batch(buf0dblwr.cc:1154),buf_flush_write_block_low(buf0flu.cc:1099),buf_flush_page(buf0flu.cc:1099),buf_flush_try_neighbors(buf0flu.cc:1453),buf_flush_page_and_try_neighbors(buf0flu.cc:1453),buf_do_flush_list_batch(buf0flu.cc:1780),buf_flush_batch(buf0flu.cc:1780),buf_flush_do_batch(buf0flu.cc:1780),pc_flush_slot(buf0flu.cc:2874),buf_flush_page_cleaner_worker(buf0flu.cc:3504),start_thread(libpthread.so.0),clone(libc.so.6)1nanosleep(libpthread.so.0),os_thread_sleep(os0thread.cc:279),buf_flush_wait_flushed(buf0flu.cc:2074),log_preflush_pool_modified_pages(log0log.cc:1531),log_checkpoint_margin(log0log.cc:1973),log_check_margins(log0log.cc:1973),log_free_check(log0log.ic:491),que_run_threads_low(log0log.ic:491),que_run_threads(log0log.ic:491),trx_purge(trx0purge.cc:1883),srv_do_purge(srv0srv.cc:2631),srv_purge_coordinator_thread(srv0srv.cc:2631),start_thread(libpthread.so.0),clone(libc.so.6)1nanosleep(libpthread.so.0),os_thread_sleep(os0thread.cc:279),buf_flush_wait_flushed(buf0flu.cc:2074),log_preflush_pool_modified_pages(log0log.cc:1531),log_checkpoint_margin(log0log.cc:1973),log_check_margins(log0log.cc:1973),log_free_check(log0log.ic:491),que_run_threads_low(log0log.ic:491),que_run_threads(log0log.ic:491),que_eval_sql(que0que.cc:1232),dict_stats_exec_sql(dict0stats.cc:311),dict_stats_save(dict0stats.cc:2415),dict_stats_update(dict0stats.cc:3112),dict_stats_process_entry_from_recalc_pool(dict0stats_bg.cc:356),dict_stats_thread(dict0stats_bg.cc:356),start_thread(libpthread.so.0),clone(libc.so.6)其中 1402 个线程是处于自旋状态，因为无奈拿到对应的 Mutex 锁而进行忙等，应该就是对应咱们看到的大量 Opening tables 的线程，然而具体什么锁须要跟踪下 MySQL 源码能力晓得。 36 个线程都是 insert 操作，最初都再期待 buf_flush_wait_flushed，貌似是期待刷盘操作。 最初三个线程别离是： page_cleaner：后盾刷脏线程，最初处于 buf_dblwr_flush_buffered_writes。purge_thread：purge 线程（清理 undo），最初处于 buf_flush_wait_flushed。dict_stats_thread：统计信息更新线程，最初处于 buf_flush_wait_flushed。简略剖析下这些线程，发现 insert、pugre_thread、dict_stats_thread 的最初一部分堆栈调用都是如下： ...

前言： 在日常应用数据库的过程中，难免会遇到须要批改账号密码的情景，比方明码太简略须要批改、明码过期须要批改、遗记明码须要批改等。本篇文章将会介绍须要批改明码的场景及批改明码的几种形式。 1.遗记 root 明码遗记 root 明码的场景还是比拟常见的，特地是本人搭的测试环境通过良久没用过时，很容易记不得过后设置的明码。这个时候个别罕用的办法是跳过权限验证，而后更改 root 明码，之后再启用权限验证。以 MySQL 5.7 版本为例简略讲下次要过程： 首先批改配置文件，在[mysqld]局部加上一句：skip-grant-tables ，加上此参数的目标是跳过权限验证。而后重启数据库，数据库再次启动后，咱们就能够不必明码间接登录数据库批改明码了。 # skip-grant-tables 模式下批改root明码[root@host ~]# mysqlWelcome to the MySQL monitor. Commands end with ; or \g.Your MySQL connection id is 16Server version: 5.7.23-log MySQL Community Server (GPL)Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.Oracle is a registered trademark of Oracle Corporation and/or itsaffiliates. Other names may be trademarks of their respectiveowners.Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.mysql> update mysql.user set authentication_string = password ('xxxxxx') where user = 'root' and host = 'localhost';Query OK, 0 rows affected, 1 warning (0.00 sec)Rows matched: 1 Changed: 0 Warnings: 1mysql> flush privileges;Query OK, 0 rows affected (0.01 sec)批改完 root 明码后，再次去除 skip-grant-tables 参数，而后重启下数据库即可。 ...

JSON_APPENDset @json = '{"a": "a", "b": "b"}';select JSON_APPEND(@json, '$[0]', 1);This function was renamed to JSON_ARRAY_APPEND() in MySQL 5.7.9; the alias JSON_APPEND() is now deprecated in MySQL 5.7, and is removed in MySQL 8.0 JSON_ARRAY_APPENDset @json = '{"a": "a", "b": "b"}';select JSON_ARRAY_APPEND(@json, '$[0]', 1, '$[1]', 1); 后续追加的元素在后面执行的后果上进行的，$ 示意以后的json数据，[1] 示意第一个元素（从0开始），当申明的下标不存在时，函数不起效。 set @json = '{"a": "a", "b": "b","c":["d"]}';select JSON_ARRAY_APPEND(@json, '$.c', 'e'); JSON_ARRAY_INSERTset @json = '["a", "b", "c"]';select JSON_ARRAY_INSERT(@json, '$[1]', 'e'); ...

7年清华人文化心智，横蛮体格1981年8月27日，在坐了18个小时（其中17小时是站席）的火车之后，16岁的侯康宁来到清华大学新生报到处实现了手续，成为清华大学自动化系1981级自12班的一员。 ▲侯康宁始终收藏着清华学生用的副食证和澡堂票。 考上清华是侯康宁人生最大的转折，“一是造就了一种虚浮做事的心态，从本科开始做研发我的项目，所有设施都要亲手做进去，基本没有夸夸其谈的机会；二是养成了锻炼身体的习惯，每天下午四点喇叭里‘为祖国衰弱工作50年’的口号一喊，大家都进去锤炼。IT界劳动强度很大，有一个好身材很重要。” （参考浏览：《自12，我的兄弟姐妹我的班》） 乏味的是，侯康宁是清华乒乓球同好会的参与者之一，而Zoho在寰球的每一个分公司都必备乒乓球台，这给了他寰球巡回打遍五大洲的机会，也因而成为Zoho体系内的乒乓名将。 聊至衰亡，侯康宁回顾了当年在清华参加的诸多我的项目、结交的好友，那段兴许永远不会为外人所知的青春，关键词是焚烧、贡献、觉醒。 然而，1988年，硕士研究生毕业的侯康宁被迫抉择来到象牙塔。导师再三挽留，认为侯康宁在科研阵线可能发明的价值远超“下海”，“就算你这孩子要来到清华，也要去科研院所，怎么能去做生意呢？”可侯康宁却有不得不肩负的责任：家中三个孩子上学，全靠父亲一人几十元的月工资撑持，“家人还住在窑洞，连瓦房都还是幻想，家里所有的钱都用在孩子教育上”。 这一年，清华大学成立清华大学科技开发总公司，这是清华大学为减速科技成果产业化成立的全校第一家综合性校办企业，若干年后以“紫光”之名为世人熟知。侯康宁入职其中，第一个月工资：274元——作为比照，他的导师当年月工资是170元左右。 “我也有现实，但更要肩负长子的责任。接下来几年工夫里，说实话人生目标十分明确，就是赚钱。” 1990年，紫光打算与日本企业成立合资软件公司，侯康宁作为14名差遣员工之一返回日本交流学习，本来没有出国想法的侯康宁感慨命运喜爱开玩笑，“那些年托福考试费用150美元，我也掏不出这个钱，没想到被公派去了日本”。 这一去便是6年。 6年旅日精修日式精益，归国守业谈起在日本这6年间最大的播种，侯康宁说，是一种被一次又一次震撼锻炼出的眼界与心理承受力。 说小事，他见证了1989年12月29日日经指数历史高点，亲自体验了日本经济泡沫幻灭后的影响；两年之后还是12月，苏联崩溃，更是对几代人的世界观造成了间接冲击。 谈小事，在全球化还是陈腐词的年代，中日员工彼此间“明天你诧异我、今天我感叹你”的状态继续了好一阵儿。先是日方被紫光团队的规格之高惊掉了眼镜，“14个清华毕业的，11个是硕士、3个是博士，日本共事很奇怪，咱就是合伙开个公司，你们怎么拉来一支国家队？”中国团队也属实对得起本人的金牌履历，短时间内语言、业余、技术……多线狂飙突进，甚至被日本共事恳求“你们要慢一点，别搞太快了。” 可不久之后，中国学霸们逐步感触到了日式团队的惊人战力，“举个例子，咱们把握了编程技术后，信心百倍的退出了一个团队，帮台湾一家钢铁公司做我的项目。这时才发现，要杰出交付一个我的项目，技术实力、编程能力所占的比重，往多说也只有40%，日本员工显著更懂业务，设计工作由他们负责；测试，积淀文档，这些咱们不感觉重要的工作，同样占据了很大的重量。” 侯康宁已经问过日本团队的共事，为什么日本企业中要求大量撰写文档，意义何在？对方的答复影响侯康宁至今：“写文档对于个体员工、对于某一个具体我的项目而言，看上去价值不高。然而，对个体、对一家继续输入价值的企业而言，文档是方法论、业务逻辑和操作流程的积淀，益处有二：第一，不怕要害员工到职；第二天，所有问题都能够回溯源头，找到关键点，并且一次谬误不会重复呈现。” “全局最优，置信个体的力量，不适度依赖蠢才、外围骨干，直到明天我的治理理念也是遵循了这些准则。” 合资公司打算最终因为种种原因搁浅，1996年，侯康宁站在人生又一个至关重要的十字路口：“当年一起去日本的中国共事，留日本的有，去欧美新加坡的有，回国的是多数。最终让我下定决心的是思考到孩子要上幼儿园，我心愿她能承受残缺的中国教育。” 有实力的人运气不会太差，困觉就有枕头递上。在日本打拼多年，能力强、性情好的侯康宁结识了不少敌人，日方被动提出“归国后是否有趣味做对日软件外包”，侯康宁一想有何不可？ 1997年4月，侯康宁在北京创立KangFei，把旅日期间修炼出的十八般武艺尽数施展，尽管没有倒退成一方巨头，但在业内也算颇有影响力。这份好名声吸引来了一位非凡的客人：2002年，Zoho前身、AdventNet-艾德威特日本区总裁找到侯康宁，“侯桑，咱们的产品打算打进中国市场，须要有一个业余的团队做做汉化、技术支持和定制开发，您这个团队不错，要不咱们两家并一家？” 侯康宁深知对日外包工作处于寰球产业链底层，本就有动向链条上游进军，单方一拍即合， 考查、讨价还价的规定流程走完，KangFei翻牌为艾德威特（中国），侯康宁的人生开启了全新篇章。 那是2003年，侯康宁没有想到这一次抉择决定了近20年的人生方向，没有想到艾德威特日后将以Zoho之名领军寰球SaaS行业。 -- 广告-- 亲历Zoho第二曲线 策略智慧护航长期主义 谈及被动启动第二曲线并取得成功的策略智慧，大家总能想到Amazon、NetFlix，事实上，曾经走进第24个年头的Zoho，亦是得益于其大胆、具备颠覆力的策略转型，一步步成为了寰球级的SaaS巨头，作为亲历者，侯康宁残缺见证了Zoho奇观。 Zoho的策略转型启动于侯康宁成为Zoho中国CEO的次年，2004年。Zoho（艾德威特）最后凭借单款产品WebNMS打天下，服务于运营商大客户。2000年，互联网泡沫幻灭，两年后余波传导至上游电信市场。Zoho创始人Sridhar Vembu敏锐察觉到危险正在急剧积攒，据理力争，确定了Zoho将来的两条策略曲线： 第一步，在WebNMS根底上研发了企业级IT运维产品ManageEngine，该产品于2004年公布；第二步，ManageEngine刚刚步入正轨，Zoho就在同年疾速投入了新品研发，建设了日后为Zoho高速成长奉献最大的SaaS产品线。 电信行业巨变的那些年，国内七大运营商死伤惨重、在2006年整合为三大运营商（挪动、联通、电信），任正非写下《华为的冬天》敲响长鸣警钟，Zoho的竞争对手一家接一家倒掉……而Zoho却依附ManageEngine大大加强了造血能力，熬过凛冬。 侯康宁表白了对Sridhar的由衷钦佩，他心惊肉跳的回顾道：“WebNMS服务于当年那些头部运营商，一共就是七大运营商、‘微小中华’加上UT斯达康这几家。起初Zoho中国帮这些巨头做做汉化、做做定制，日子挺舒服。也正是因为这种舒适感，Sridhar强推ManageEngine的时候，外围团队都示意拥护，销售、财务、研发的反对派中有些甚至是他的亲戚，但他据理力争，要求必须做出一款开箱即用、服务于产业链上游中小企业的产品，不换思维就换人。待到运营商大洗牌，那些看似不可撼动的巨头转瞬隐没，咱们才意识到Sridhar的判断有如许正确。”事实上，以侯康宁为代表的各大区诸侯，起初也不免对客户类型的转变、新产品销售全流程搭建等等挠头不已，但惨烈的市场变迁成为了最具说服力的教程。 ManageEngine作为WebNMS的延长尚且引发了如此微小的争议，可想而知，Zoho试水云计算、勇闯SaaS行业的决定，在其外部掀起了怎么的滔天巨浪。Sridhar力主之下，Zoho在2004年倾尽全力防御云计算——作为参考，Zoho当年惟一的竞争对手Google Docs上线于2006年，马云、马化腾、李彦宏那场闻名于世的云计算前景之辩更要等到2010年——甚至直到那一年，三人中也只有马云看好“云”的前景。 2004年到2005年，Zoho用一年工夫研发了其第一款SaaS产品Zoho Writer，一款在线文档编辑工具；2006年，Zoho又推出了在线表格Zoho Sheet、在线演示文档Zoho Show……一家以服务运营商为基底的软件企业，火力全开地搞出了一套云计算Office全家桶。 走得太早，有可能是先驱，也有可能是先烈。谈起Zoho云计算转型之旅，侯康宁感叹颇多，“如果不是Zoho的策略和战术层面做对了很多事，也未必能保持到胜利的那一天”。 策略层面，Zoho给予了云产品足够长的成长周期、储备了足够丰盛的弹药，ManageEngine这款面向中小客户的产品完满表演了承前启后的策略轴承，在原有战场开疆拓土、继续造血、反哺云产品线。 战术层面，Zoho提供了性能优良的收费产品作为引流产品，之所以率先推出Office全家桶便是出于这一目标，待到用户习惯逐步养成，2006年，Zoho推出了现在SaaS线的主打产品：须要付费的Zoho CRM。接着，随着CRM的市场占有率晋升及其他SaaS产品的一直迭代，奠定了Zoho现在在SaaS产品线上的非凡打法：企业工具全家桶。 凭借16年来积攒的40多款SaaS产品，Zoho将本人变成了企业客户的云管家，治理服务客户类工具，如CRM、客服；员工协同办公工具，如Office、邮箱、即时通讯；日常办公管理工具，如HR、财务等……大多数企业的通用需要，Zoho产品矩阵都能满足。更重要的是，这40多款产品数据互联互通，能无效解决企业因应用多家SaaS产品造成信息孤岛的痛点。 Zoho中国的云产品线真正成为盈利点，通过了多长时间？侯康宁微笑着给出了一个惊心动魄的数字：8年。“Zoho是在中国市场最先发展云计算宣讲的企业之一，大家第一反馈很排挤，为什么我要把我的数据交给你们？听着就很不平安。逼得咱们想各种交换话术，最初想出了一个比如：银行，起初大家也不违心把钱存在里面，可逐步大家意识到，业余的保存、业余的金融服务，其实比把钱放家里要平安得多，还有增值，云计算也是同样情理。咱们获取到的第一批客户是一批中小企业，他们须要服务，不在乎数据放在哪儿”。 侯康宁谈导流产品 只管Zoho是“导流产品战术”的胜利实践者，但侯康宁并不认为导流产品是必须的，“性能太差用户不会喜爱，老本太高又不太值得做，还是要聚焦外围产品是否可能感动客户，否则客户流进来也留不住”。 顺利应答自营挑战 放弃衰弱再战30年 2016年，侯康宁迎来了Zoho中国区成立以来的又一次挑战。之前11年，Zoho中国的SaaS销售工作委托给一家名为百会的代理公司，单方单干比拟默契，百会的业余能力以及对中国市场特色的深度了解，为Zoho中国提供了不小的反对。遗憾的是，这一年百会因为外部经营呈现一些情况，不得不终止与Zoho中国的服务，Zoho中国也不再思考代理商模式。 发出市场销售模块，压力不堪称不大，Zoho公司外部有一条极其反常识的规定：区域市场的营销收入，不得超过区域总营收的20%。尽管有13年的市场耕耘作为铺垫，但在刻薄的条件限度下，Zoho中国团队高低不免手心冒汗。 侯康宁倒是信心十足，“无非又一次学习而已，我一个学工程的，做了软件、做了治理，当初就是再学习下销售而已，何况咱们还有杰出的骨干团队”。联合过往教训与市场反馈的数据，Zoho中国疾速建设起了一套性价比颇高的推广战术：销售以线上渠道为主，如百度搜寻，70%的SaaS营收靠直销团队，且销售团队人数管制在20多人左右——相较中国市场同级别的SaaS厂商，或者与点“黯然失色”了。 自营以来，Zoho中国战绩亮眼，不仅实现盈利，还放弃着70%的年增速，超过了Zoho在寰球市场40%的均匀增速。 接下来，Zoho又开始寻找新的增长曲线，2017年，Zoho开始将其SaaS产品线整合为Zoho One，剑指近几年的行业热点：企业操作系统。“Sridhar认为，云计算呈现以前，一家公司想要成为企业的操作系统是不可能的，因为传统企业软件的功能模块彼此独立，每个部门都是一座信息孤岛。但在云时代，这些信息孤岛齐全能够造成对立的解决方案，在利用与利用之间、人与人之间实现互通。此外，企业操作系统还将承当起企业对接上下游与客户的生态控制中心职能”，侯康宁介绍说。 面对AWS、Azure、阿里云、Salesforce、IBM、华为等不同必由之路的巨头对手，Zoho的劣势有二：第一，40多款产品组成了互联互通的“工具箱”，构建了一个生态，让用惯了Zoho的企业客户有很高的替换老本。将这些产品整合为Zoho One后，Zoho进一步通过变更免费形式来强化这种残缺生态一体性——以2800元/用户的年费销售整套产品，用户一次可应用包含CRM在内的30多个工具。 第二，Zoho在找到新增长引擎SaaS之后也始终没放下的电信业务，基于此，目前Zoho正在拓展与老业务WebNMS一脉相承的物联网开发平台，随着云计算、传感器技术的倒退，将来，各类型企业的数据化和智能化都会以物联网+云为根底，这是一个“物理世界逐步上云”的过程。 新策略、新挑战，侯康宁一并哂纳。“清华校训‘为祖国衰弱工作50年’，我曾经工作了30多年，还有20年的事件要做。技术出身的敌人，学习能力强、摸索世界的意志强烈、解决问题的办法也多，咱们是真正活到老、学到老、战斗到老的一群人。”

子查问是指在一个SELECT语句中嵌套另一个SELECT语句。 通常来讲，应用子查问的益处如下： 子查问容许结构化的查问，这样就能够把一个查问语句的每个局部隔开。子查问提供了另一种办法来执行有些须要简单的JOIN和UNION来实现的操作。在许多人看来，子查问可读性较高。一个子查问会返回一个标量（繁多值）、一个行、一个列或一个表（一行或多行及一列或多列），这些子查问被称为标量、列、行和表子查问。可返回一个特定品种后果的子查问常常只用于特定的语境中。子查问能够包含一般SELECT能够包含的任何关键词或子句，如DISTINCT、GROUP BY、ORDERBY、LIMIT、JOIN、UNION等。 子查问的限度是其内部语句必须是以下语句之一：SELECT、INSERT、UPDATE、DELETE、SET或DO。还有一个限度是，目前用户不能既在一个子查问中批改一个表，又在同一个表中进行抉择，尽管这样的操作可用于一般的DELETE、INSERT、REPLACE和UPDATE语句中，然而对子查问不能够同时进行这样的操作。 罕用关键词（ANY/IN/SOME/ALL）应用ANY、IN、SOME和ALL进行子查问的语法如下： operand comparison_operator ANY (subquery)operand IN (subquery)operand comparison_operator SOME (subquery)operand comparison_operator ALL (subquery)ANY关键词必须与一个比拟操作符一起应用。ANY关键词的意思是“对于子查问返回的列中的任一数值，如果比拟后果为TRUE，则返回TRUE”。例如： SELECT s1 FROM t1 WHERE s1 > ANY (SELECT s1 FROM t2); 关键词IN是“= ANY”的别名，关键词SOME是ANY的别名。 ALL关键词也必须与比拟操作符一起应用。ALL的意思是“对于子查问返回的列中的所有值，如果比拟后果为TRUE，则返回TRUE”。 独立子查问独立子查问是不依赖内部查问而运行的子查问。 举个例子，当初有一张订单表，咱们须要查问出每月最初理论订单日期产生的订单。在这里，每月最初理论订单的日期可能并不是每月的最初一天。因而，每月最初订单日期须要通过子查问来判断。查问语句如下： SELECT orderid,customerid,employeeid,orderdate FROM orders WHERE orderdate IN ( SELECT MAX(orderdate) FROM orders GROUP BY (DATE_FORMAT(orderdate,'%Y%m')) )子查问通过把订单按月分组并返回每个分组中最大的日期后果，这就是每个月最初订单生成的日期。而后内部查问通过子查问取得的日期来获得所有的订单信息。 这个问题看似失去了解决，实际上并没有这么简略。因为在这个数据量并不大的数据库中执行上述SQL语句居然须要6.08秒，如果咱们用EXPLAIN来对语句进行剖析，就能够找到问题的所在——独立子查问被转化成了相干子查问。 这个是MySQL优化器对IN子查问优化时存在的一个问题，MySQL优化器对于IN语句的优化是“LAZY”的。对于IN子句，如果不是显式的列表定义，如IN('a','b','c')，那么IN子句都会被转换为EXISTS的相干子查问。 如果子查问和内部查问别离返回M和N行，那么该子查问被扫描为O（N+M*N）而不是O（M+N）。 因而，对于上述问题的SQL语句，MySQL数据库的优化器将其对应地转换为如下的相干子查问： SELECT orderid,customerid,employeeid,orderdate FROM orders AS A WHERE EXISTS ( SELECT ＊ FROM orders GROUP BY(DATE_FORMAT(orderdate,'%Y%M')) HAVING MAX(orderdate)= A.OrderDate );须要留神的是，在大多数状况下，MySQL数据库都将独立子查问转换为相干子查问。 ...

简介EXISTS用于查看子查问是否至多会返回一行数据，该子查问实际上并不返回任何数据，而是返回值True或False。 EXISTS 指定一个子查问，检测行的存在。语法：EXISTS subquery。参数 subquery 是一个受限的 SELECT 语句 （不容许有 COMPUTE 子句和 INTO 关键字）。后果类型为 Boolean，如果子查问蕴含行，则返回 TRUE。 示例一张流动配置主表activity_main，通过act_code来惟一表明一场流动，流动举办地点适配表activity_area，通过act_code与主表进行关联，流动奖品表activity_sku，通过act_code与主表进行关联。 流动主表CREATE TABLE `activity_main` (`id` bigint(20) NOT NULL AUTO_INCREMENT,`act_code` varchar(255) NOT NULL COMMENT '流动代码',`act_name` varchar(255) NOT NULL COMMENT '流动名称',PRIMARY KEY (`id`),UNIQUE KEY `uniq_code` (`act_code`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='流动主表'流动在哪些网站举办的适配表CREATE TABLE `activity_area` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `act_code` varchar(255) NOT NULL COMMENT '流动代码', `area` varchar(255) NOT NULL COMMENT '参加此流动的网站', PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='流动适配的网站列表'流动奖品表CREATE TABLE `activity_sku` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `act_code` varchar(255) NOT NULL COMMENT '流动代码', `sku` varchar(255) NOT NULL COMMENT '流动赠送的商品', PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='流动赠品表'比拟应用 EXISTS 和 IN 的查问这个例子比拟了两个语义相似的查问。第一个查问应用 IN 而第二个查问应用 EXISTS。留神两个查问返回雷同的信息。 ...

类型属性数据类型在数据库中扮演着根底但又十分重要的角色。对数据类型的抉择将影响与数据库交互的应用程序的性能。通常来说，如果一个页内能够寄存尽可能多的行，那么数据库的性能就越好，因而抉择一个正确的数据类型至关重要。 首先来介绍两个属性：UNSIGNED和ZEROFILL，是否应用这两个属性对抉择数据类型有着莫大的关系。 因为MySQL是用C语言编写的，所以一些在C语言外面呈现的陷阱在MySQL外面也会呈现。比方，在MySQL数据库中，对于UNSIGNED数的操作，其返回值都是UNSIGNED的。假如a和b是两个UNSIGNED INT，a的值为 1，b的值为 2，执行a - b的后果会等于 4294967295 ，而非 -1。 那么，怎么取得 -1 这个值呢？这须要对SQL_MODE这个参数进行设置，例如：SET sql_mode='NO_UNSINED_SUBTRACTION'; 举荐的做法是尽量不要应用UNSIGNED，因为可能会带来一些意想不到的成果。另外，对于INT类型可能寄存不了的数据，INT UNSIGNED同样可能寄存不了，与其如此，还不如在数据库设计阶段将INT类型晋升为BIGINT类型。 另外，对于SQL_MODE的值，强烈建议开发人员在生产环境中将这个值设为严格模式，严格模式是指将SQL_MODE变量设置为STRICT_TRANS_TABLES或STRICT_ALL_TABLES中的至多一种。 日期和工夫类型MySQL数据库中有五种与日期和工夫无关的数据类型，各种日期数据类型所占空间如下所示。 DATETIME 和 DATEDATETIME占用8字节，是占用空间最多的一种日期类型。它既显示了日期，同时也显示了工夫。其能够表白的日期范畴为“1000-01-0100：00：00”到“9999-12-31 23：59：59”。 DATE占用3字节，可显示的日期范畴为“1000-01-01”到“9999-12-31”。 从MySQL 5.6.4版本开始，MySQL减少了对秒的小数局部的反对，最大能够反对到微秒。 TIMESTAMPTIMESTAMP占用4字节，显示的范畴为“1970-01-0100:00:00”UTC到“2038-01-19 03:14:07”UTC。其理论存储的内容为“1970-01-01 00:00:00”到以后工夫的秒数。 TIMESTAMP类型还有以下特点： 在建表时，列为TIMESTAMP的日期类型能够设置一个默认值。在更新表时，能够设置TIMESTAMP类型的列自动更新工夫为以后工夫。在MySQL 5.5及之前版本中，仅能对一个工夫戳字段定义DEFUALT CURRENT_TIMESTAMP或ON UPDATE CURRENT_TIMESTAMP，但从MySQL 5.6版本开始勾销了该限度。 在MySQL 5.6版本中参数explicit_defaults_for_timestamp默认值为1，在MySQL 5.7版本中参数explicit_defaults_for_timestamp默认值为0;在MySQL 5.5和MySQL 5.7版本中timestamp类型默认为NOT NULL,在在MySQL 5.6版本中timestamp类型默认为NULL。 YEAR和TIMEYEAR类型占用1字节，并且在定义时能够指定显示的宽度为YEAR（4）或YEAR（2），对于YEAR（4），其显示年份的范畴为1901～2155；对于YEAR（2），其显示年份的范畴为1970～2070。 TIME类型占用3字节，显示的范畴为“-838：59：59”～“838：59：59”。 相干函数NOW、CURRENT_TIMESTAMP和SYSDATECURRENT_TIMESTAMP是NOW的同义词，也就是说两者是雷同的。SYSDATE函数返回的是执行到以后函数时的工夫，而NOW返回的是执行SQL语句时的工夫。 工夫加减函数如果想对工夫类型值进行减少或缩小，并不能间接加上或减去一个数字，而须要应用特定的函数，如DATE_ADD或DATE_SUB，前者示意减少，后者示意缩小。其具体的应用办法有DATE_ADD（date，INTERVAL expr unit）和DATE_SUB（date，INTERVAL expr unit），例如： SELCET NOW() AS now, SELECT DATE_ADD(NOW(), INTERVAL 1 DAY) AS tomorrow, SELECT DATE_SUB(NOW(), INTERVAL 1 YEAR) AS last_year)字符类型字符集和排序规定能够通过命令SHOW CHARSET能够查看MySQL数据库反对的字符集，以及通过命令SHOW COLLATION来查看反对的各种排序规定，也能够通过information_schema架构下的表COLLATIONS来查看。每个字符集有一个默认的排序规定，对于排序规定有一些罕用的命名标准。如_ci结尾示意大小写不敏感（caseinsensitive），_cs示意大小写敏感（case sensitive），_bin示意二进制的比拟（binary）。 ...

背景本计划解决了windows下装置MySQL过程繁琐的问题。 是真正的免装置绿色办法，不必配环境变量，不必执行install命令，不必配置my.ini文件。 步骤下载下载mysql-8.0.22-winx64.zip 解压到D盘 初始化MySQL的bin目录下执行mysqld --initialize-insecure 命令胜利生成data目录，同时生成无明码的root用户 启动MySQLbin下执行mysqld --console 设置root明码执行mysql -u root -p连入数据库，明码不必输出，间接按回车进入mysql>命令行 执行mysql> ALTER USER 'root'@'locoalhost' IDENTIFIED WITH mysql_native_password BY'123456'; 用navicat测试连贯 此时数据库只能在本机拜访，无奈近程拜访。 设置近程拜访进入mysql库，批改root账号对应的host值。 update user set host = '%' where user = 'root'; 必须执行flush privileges;能力失效 当初能够从另一台主机连贯数据库了。 可能遇到的问题如果执行过程报错 下载微软罕用运行库合集，间接装置能解决问题 论断计划为纯绿色办法，不批改window注册表的信息，当然也无奈用net start mysql启动命令。益处是不净化零碎环境，数据库坏了删除整个目录，从新解压一份MySQL从新执行本文过程就行了。

7、索引概念：索引index是帮忙MYSQL高效获取数据的数据结构。索引是数据结构（树） MYSQL里的索引是B+树 索引相似于书的目录 SQL优化的起因：性能低，执行工夫长，等待时间长，sql语句欠佳（连贯查问）、索引生效、服务器参数设置不周 SQL编写过程： select .. from .. join ... on ..where ..group by ... having...order by...limit..解析过程 先解析 from.... on .. join...where ..group by ...having ..select ..order by limit索引的底层原理B+树 三层B+树，一个关键字对应一个指针，对应一个指数 B+树的数据全副寄存在叶节点中， B+树中查问任意的数据次数：n次（B+树的高度） 7.1、索引分类单列索引 主键索引（PRIMARY KEY) 惟一的标识，主键不可反复 惟一索引 (UNIQUE KEY/index) 避免出现反复的列，能够反复，多个列都能够标识位 惟一索引 人们创立惟一索引的目标往往不是为了进步访问速度，而只是为了==防止数据呈现反复==。 惯例索引 (KEY/INDEX) 默认的，index。key关键字来设置全文索引 (FullText) 疾速定位数据复合索引 多个列形成的索引（相当于二级目录： z :zhao) 比方 先找 name列 再找 age，（name，age）不肯定要都查问，只有反复的状况下才须要，复合索引能够有多个列创立索引CREATE 索引类型 索引名 on 表名(字段）---创立复合索引-----【形式一】create index dept_index on tb(dept,name)--tb(dept,name) 会主动生成合乎索引----【形式二】alter table 表名 索引类型 索引名(字段)alter table tablename add unique index_name(name)删除索引drop index 索引名 on 表名show index from 表名 \G7.2、索引应用准则索引的弊病索引不是越多越好，不要对常常变动的数据加索引小数据量的数据不要加索引很少应用的字段也不倡议加索引索引尽管能够进步查问的效率，然而会升高增删改的效率索引的长处进步查问效率（升高IO使用率）升高CPU使用率7.3、SQL性能问题剖析SQL的执行打算 ： explain ， 能够模仿SQL 优化器执行SQL语句MySQL查问优化其会烦扰咱们的优化【mysql有一个查问优化器】查问执行打算 ...

Mysql索引索引是什么索引是帮忙mysql高效获取数据的数据结构，数据库索引好比一本书前的目录，能放慢数据库的查问速度。索引往往是存储在磁盘上的文件中劣势：能够进步数据检索的效率劣势：索引会占据磁盘空间，会升高更新表的效率 索引类型主键索引：索引列中的值必须是惟一的，不容许有空值一般索引：mysql中一般索引类型，没有什么限度，容许在定义索引的列中插入反复值和空值惟一索引：索引列中的值必须是惟一的，然而容许为空值全文索引：在进行like含糊查问时效率比拟低，这时能够创立全文索引空间索引：mysql在空间索引这方面遵循OpenGIS几何数据模型规定前缀索引：能够指定索引列的长度，然而数值类型不能指定 索引的数据结构Hash表二叉树B+树 mysql的索引实现两种存储引擎的索引实现：MyISAM索引和InnoDb索引 创立单个字段索引的语法：CREATE INDEX 索引名 on 表名(字段名)创立联结索引的语法：CREATE INDEX 索引名 on 表名(字段名1，字段名2)索引命名格局个别能够这样：idx_表名_字段名。留神有长度限度删除索引：DROP INDEX 索引名 ON 表名中到大数据量表适宜应用索引小数据量表，大部分状况全表扫描效率更高特大数据量表，建设和应用索引的代价会随之增大，适宜应用分区或分库 索引：排好序的疾速查找数据结构单值索引： 即一个索引只蕴含单个列，一个表能够有多个单例索引惟一索引： 索引列的值必须惟一，但容许有空值复合索引： 即一个索引蕴含多个列 根本语法：创立： create [unique] index indexName ON mytable(columnname(length));alter mytable add[unique] index[indexName] ON(columnname(length));删除：DROP INDEX[indexName] ON mytable; 查看：SHOW INDEX FROM table_name\G mysql索引构造：BTree索引、Hash索引 频繁作为查问条件的字段应该创立索引频繁更新的字段不适宜创立索引where条件里用不到的字段不创立索引 不适宜建设索引表记录太小常常增删改的表数据反复且散布均匀的表的字段 MyISAM和InnoDBMyISAM：只有表级锁InnoDB：反对行级锁、和表级锁。默认为行级锁 表级锁MySQL中锁定粒度最大的一种锁，对以后操作的整张表加锁，实现简略，资源耗费也比拟少，加锁快，不会呈现死锁，触发锁抵触的概率最高，并发度最低，MyISAM和InnoDB都反对表级锁 行级锁MySQL中锁定粒度最小的一种锁，只针对以后操作的行进行加锁，行级锁能大大减少数据库操作抵触，其加锁粒度最小，并发度高，但加锁的开销也最大，加锁慢，会呈现死锁 MyISAM只有表级锁，InnoDB行级锁和表级锁（默认行级锁） 垂直分区与程度分区依据数据库外面数据表的相关性进行拆分。垂直拆分是指数据表列的拆分，把一张列比拟多的表拆分为多张表。 垂直拆分的长处： 能够使得列数据变小，在查问时缩小读取的Block数，缩小I/O次数。垂直分区能够简化表的构造，易于保护垂直拆分的毛病： 主键会呈现冗余，须要治理冗余列，并会引起join操作，能够通过在应用层进行join来解决。垂直分区会让事务变得更加简单。 程度分区： 放弃数据表构造不变，通过某种策略存储数据分片。这样每一片数据扩散到不同的表或者库中，达到了分布式的目标。程度拆分能够撑持十分大的数据量 SQL语句的执行流程权限校验 -> 查问缓存 -> 分析器 -> 优化器 -> 权限校验 -> 执行器 -> 引擎

在mysql中咱们能够应用ALTER命令来批改数据库表的名称，例如： ALTER TABLE test_test RENAME TO wj_test;执行如上命令咱们就能够将数据库中的test前缀批改成wj 然而一个数据库中有人多的表，咱们一个一个的写这样的话是很浪费时间的，那么如何可能批量生成下面相似的命令，一次性批量将数据库中所有的表的前缀全都变更呢？ 这时候咱们能够应用select命令来查问到指定前缀的表，而后拼接成咱们下面的命令，这时候咱们就能够失去多条ALTER命令，这样咱们就能够一次性将数据库中所有的表前缀批改了 如： SELECTCONCAT('ALTER TABLE ',table_name,' RENAME TO wj_',substring(table_name, 5),';')FROMinformation_schema. TABLESWHEREtable_schema = 'test'AND table_name LIKE 'test_%';命令解释： 将名称为test的数据库中所有蕴含test_表查问除了，并组合成如下构造： ALTER TABLE 表名 RENAME TO 变更表名依据下面的命令，查问构造如下： 将查问后果的命令一次执行后，咱们就能够将test中所有蕴含test前缀的表编程wj前缀

七种连贯 查问表A和表B共有 ` select * from t_emp a inner join t_dept b on a.deptId = b.id;`A、B两表共有+A的独有 select * from t_emp a left join t_dept b on a.deptId = b.id;A、B两表共有+B的独有 select * from t_emp a right join t_dept b on a.deptId = b.id;A的独有 select * from t_emp a left join t_dept b on a.deptId = b.id where b.id is null; B的独有 select * from t_emp a right join t_dept b on a.deptId = b.id where a.deptId is null; A独有+B独有 ...

char和varchar类型是类似的，然而他们在存储和检索上也存在不同，并且它们在最大长度和结尾是否保留空格上也有不同。 char的长度在你创建表格的时候由你本人定义的.长度的范畴是0-255。当char值被存储的时候，它应用空格填充到规定的长度。当查看char值时，结尾空格将删除尾部空格，除非PAD_CHAR_TO_FULL_LENGTH这个SQL_MODE被启用。 varchar列中的值是可变的字符串，长度规定在0到65535范畴内。VACHAR的无效最大长度受限于最大行大小和应用的字符集。 与char产生鲜明对比的是，varchar的值被用1-2两个字节存储前缀数据。前缀的长度表明字节数，如果不超过255字节，一列应用一个长度的字节来示意。如果超过255字节，则应用两个长度的字节。 如果没启动严格的SQL模式，对CHAR或者VARCHAR进行赋值阶段，如果列超过了列的最大长度，值会裁剪而后生成一个正告。如果应用严格的SQL模式，会产生一个谬误。 不论应用那种SQL模式，VARCHAR在插入前都会截断超出列长度的结尾空格，并生成正告。 char & varchar设置的最长度仅为8，然而上面的语句是能够执行胜利的update `SimpleBookStore`.`Book_0` set `text`='123123 ' where `id`='2' 和规范的SQL保持一致，VARCHAR的值当他们被存储的时候值不会被填充，被存储的时候尾部空格会被存储和检索。 下表通过显示将各种字符串值存储到CHAR（4）和VARCHAR（4）列中的后果来阐明CHAR和VARCHAR之间的区别（假如该列应用单字节字符集，如latin1）。 显示在表的最初一行中的值仅在不应用严格的SQL模式时才实用。 如果启用了严格模式，则不会存储超过列长度的值，并且会导致谬误。 InnoDB将长度大于或等于768字节的固定长度字段编码为可变长度字段，能够将其存储在页面外。 例如，如果字符集的最大字节长度大于3（如utf8mb4一样），则CHAR（255）列能够超过768个字节。 如果给定值存储在CHAR（4）和VARCHAR（4）列中，则从这些列检索的值并不总是雷同的，因为检索时会从CHAR列中删除尾随空格。 以下示例阐明了这种差别： mysql> CREATE TABLE vc (v VARCHAR(4), c CHAR(4));Query OK, 0 rows affected (0.01 sec)mysql> INSERT INTO vc VALUES ('ab ', 'ab ');Query OK, 1 row affected (0.00 sec)mysql> SELECT CONCAT('(', v, ')'), CONCAT('(', c, ')') FROM vc;+---------------------+---------------------+| CONCAT('(', v, ')') | CONCAT('(', c, ')') |+---------------------+---------------------+| (ab ) | (ab) |+---------------------+---------------------+1 row in set (0.06 sec)CHAR，VARCHAR和TEXT列中的值依据调配给该列的字符集排序规定进行排序和比拟。 ...

应用范畴MySQL语句中的limit字句能够帮忙咱们在应用执行查问的时候，返回数据库两头的数据或者是只提取前几段数据 应用语法SELECT * FROM table LIMIT \[offset,\] rows | rows OFFSET offset它常常被用于强制 SELECT 语句执行时只返回指定的记录数。 SELECT * FROM table LIMIT  起始数据段, 提取数据的数量LIMIT 承受一个或两个数字参数，参数必须是一个整数 如果给定两个参数，第一个参数指定第一个返回记录行的偏移量，第二个参数指定返回记录行的最大数目。初始记录行的偏移量是 0(而不是 1) 例子数据库信息 应用LIMIT只提取第一条到第三条数据 SELECT * FROM \`university\` LIMIT 0, 3 #留神开始的数据条为0, 检索记录行 0到3 应用LIMIT只提取第3条到第6条数据 SELECT * FROM \`university\` LIMIT 2,4#检索记录值 第3到第6个。

Mysql索引索引是什么索引是帮忙mysql高效获取数据的数据结构，数据库索引好比一本书前的目录，能放慢数据库的查问速度。索引往往是存储在磁盘上的文件中劣势：能够进步数据检索的效率劣势：索引会占据磁盘空间，会升高更新表的效率 索引类型主键索引：索引列中的值必须是惟一的，不容许有空值一般索引：mysql中一般索引类型，没有什么限度，容许在定义索引的列中插入反复值和空值惟一索引：索引列中的值必须是惟一的，然而容许为空值全文索引：在进行like含糊查问时效率比拟低，这时能够创立全文索引空间索引：mysql在空间索引这方面遵循OpenGIS几何数据模型规定前缀索引：能够指定索引列的长度，然而数值类型不能指定 索引的数据结构Hash表二叉树B+树 mysql的索引实现两种存储引擎的索引实现：MyISAM索引和InnoDb索引 创立单个字段索引的语法：CREATE INDEX 索引名 on 表名(字段名)创立联结索引的语法：CREATE INDEX 索引名 on 表名(字段名1，字段名2)索引命名格局个别能够这样：idx_表名_字段名。留神有长度限度删除索引：DROP INDEX 索引名 ON 表名中到大数据量表适宜应用索引小数据量表，大部分状况全表扫描效率更高特大数据量表，建设和应用索引的代价会随之增大，适宜应用分区或分库 索引：排好序的疾速查找数据结构单值索引： 即一个索引只蕴含单个列，一个表能够有多个单例索引惟一索引： 索引列的值必须惟一，但容许有空值复合索引： 即一个索引蕴含多个列 根本语法：创立： create [unique] index indexName ON mytable(columnname(length));alter mytable add[unique] index[indexName] ON(columnname(length));删除：DROP INDEX[indexName] ON mytable; 查看：SHOW INDEX FROM table_name\G mysql索引构造：BTree索引、Hash索引 频繁作为查问条件的字段应该创立索引频繁更新的字段不适宜创立索引where条件里用不到的字段不创立索引 不适宜建设索引表记录太小常常增删改的表数据反复且散布均匀的表的字段

本文翻译自 Percona 官网博客，实用于 MySQL 5.6 及 5.7 版本。作者：Stephane Combaudon原文：https://www.percona.com/blog/2014/01/28/10-mysql-performance-tuning-settings-after-installation/在本博客中，咱们将和大家探讨下 MySQL 数据库装置后，倡议调整的十个性能设置参数。 通常状况下，当咱们须要进行 MySQL 性能审计时，咱们将审查 MySQL 配置并提出改良倡议。在大多数状况下，咱们只倡议装置后更改一些外围的 MySQL 性能调优参数，即便有数百个选项可用。这篇文章的目标是给你列出一些最要害的参数设置，并通知你如何去调整它们。 在开始调整之前即便是有教训的人也会犯一些会造成许多麻烦的谬误。因而，在利用本文举荐的配置项之前，请牢记上面的几项： 每次更改一个设置！这是验证设置是否无效的惟一办法。大多数配置项能够在运行时应用 SET GLOBAL 命令来批改。这种形式十分不便，并且如果批改后呈现问题，还能马上恢复原设置。但到最初，依然须要把这个扭转写到配置文件中，使之永恒失效。有时候即便 MySQL 重启后，配置文件中的参数也不失效。这时候你须要思考：你应用正确的配置文件了吗？你把这个参数放在正确的中央了吗？（在这篇文章中的所有配置都属于[mysqld]局部）如在更改配置后数据库无奈启动，须要查看是否应用正确的单位？例如， innodb_buffer_pool_size 的单位是 byte，而 max_connection 是没有单位的。在配置文件中不容许反复设置。如果要跟踪配置的更改，请应用版本控制。不要做天真的数学算法，比方“我的新服务器的 RAM 是旧的 2 倍，因而能够把所有的配置项的值都设置成之前的 2 倍”。根底设置这里次要解说 3 个十分重要的 MySQL 性能配置项，你应该常常会看到这些参数。如果你没有调整，很可能会遇到问题。 innodb_buffer_pool_size： 这是任何应用 InnoDB 存储引擎的 MySQL 在装置后第一个应该要查看的配置。Buffer pool 是用来缓存数据和索引的，应该调配尽可能大的内存，以确保在进行大多数读取操作时是读内存而不是读磁盘。典型的设置值为 5-6GB(8GB RAM)，20-25G(32GB RAM)，100-120GB(128GB RAM)。 innodb_log_file_size： 这个选项是设置 redo 日志（重做日志）的大小。redo 日志是用来确保写入的数据可能疾速地写入，并且长久化，还能够用于解体复原(crash recovery)。MySQL 5.1 之前，这个选项很难去进行调整，因为你既想要加大 redo 日志来进步性能，又想要减小 redo 日志来进行疾速的解体复原。侥幸的是，自 MySQL 5.5 之后，解体复原的性能有了很大的进步，当初你能够领有疾速写入性能的同时，还能满足疾速解体复原。始终到 MySQL 5.5，redo 日志的总大小被限度在 4GB (默认有 2 个日志文件)。这个在 MySQL 5.6 中被减少了。 ...

第一步：启动数据库，并输出 数据库的 登录用户名及明码；1.启动数据库： 1. 启动命令 [root@localhost src]# systemctl start mariadb2. 重启命令 [root@localhost src]# systemctl restart mariadb3. 敞开命令 [root@localhost src]# systemctl stop mariadb4. 设定开机自起 [root@localhost src]# systemctl enable mariadb 5. 敞开开机自起 [root@localhost src]# systemctl disable mariadb 6. 登录数据库，输出用户名及明码mysql -u -p;第二步：配置数据库权限1.切换指定数据库，如mysql切换至mysql数据库2.批改数据库表1）查看数据表show tables;2)查问user表中的host/root/password3）将host=“localhost” 改为 “%”，这样操作是为了将本地ip能够拜访的权限批改为 任意的ip都能够拜访！4）刷新数据库拜访权限 第三步：配置防火墙策略查看防火墙状态：firewall-cmd --state开机是否主动启动防火墙systemctl disable firewalld.servicesystemctl enable firewalld.service 手动开敞开防火墙systemctl stop firewalld.servicesystemctl start firewalld.service 第四步：主从库设置指令129 主库SHOW MASTER STATUS; 130 从库 CHANGE MASTER TO MASTER_HOST="192.168.126.129",MASTER_PORT=3306,MASTER_USER="root",MASTER_PASSWORD="root",MASTER_LOG_FILE="mysql-bin.000002",MASTER_LOG_POS=245; START SLAVE; ...

书籍信息书名: 高性能MySQL（第二版）原作名: High Performance MySQL, 2nd Edition作者:豆瓣评分: 8.8分(422人评估)标签: mysql,数据库,MySQL,性能,计算机,Database,优化,OReilly内容简介本书荣获2009年Jolt图书大奖，是不可多得的分享MySQL实用教训的图书。它岂但能够帮忙MySQL初学者进步应用技巧，更为有教训的MySQL DBA指出了开发高性能MySQL利用的路径。全书蕴含14章和4个附录，内容笼罩MySQL零碎架构、设计利用技巧、SQL语句优化、服务器性能调优、系统配置治理和平安设置、监控剖析，以及复制、扩大和备份/还原等主题，每一章的内容自成体系，适宜各畛域技术人员作选择性的浏览。汇聚驰名MySQL专家在实践中构建大型零碎的多年教训。分析MySQL外部工作机制，领导读者MySQL开发出疾速牢靠的零碎。实例解说MySQL实用又平安的高性能之路。作者简介Baron Schwartz 是一名软件工程师，他住在弗吉尼亚州的Charlottesville，在网上用的名字是Xaprb，这是他名字的第一局部按QWERTY键盘的程序打在Dvorak键盘上时显示进去的名字。当他不忙于解决乏味的编程挑战时，Baron就会和他的妻子Lynn、狗Carbon一起享受空闲时光。他的对于软件工程的博客地址是http://www.xaprb.com/blog。Peter Zaitsev，MySQL AB公司高性能组的后任经理，现正运作着mysqlperformanceblog.com 网站。他擅长于帮忙管理员为每天有着数以百万计访问量的网站修补破绽，应用数百台服务器来解决TB级的数据。他经常为了找到一个解决方案而批改和降级软硬件（比方查问优化）。Peter还常常在讨论会上发表演讲。Vadim Tkachenko，Perc…Baron Schwartz 是一名软件工程师，他住在弗吉尼亚州的Charlottesville，在网上用的名字是Xaprb，这是他名字的第一局部按QWERTY键盘的程序打在Dvorak键盘上时显示进去的名字。当他不忙于解决乏味的编程挑战时，Baron就会和他的妻子Lynn、狗Carbon一起享受空闲时光。他的对于软件工程的博客地址是http://www.xaprb.com/blog。Peter Zaitsev，MySQL AB公司高性能组的后任经理，现正运作着mysqlperformanceblog.com 网站。他擅长于帮忙管理员为每天有着数以百万计访问量的网站修补破绽，应用数百台服务器来解决TB级的数据。他经常为了找到一个解决方案而批改和降级软硬件（比方查问优化）。Peter还常常在讨论会上发表演讲。Vadim Tkachenko，Percona公司的合伙人，该公司是一家业余的MySQL性能征询公司。他过来是MySQL AB公司的性能工程师。作为一名在多线程编程和同步畛域里的专家，他的次要工作是基准测试、特征分析和找出零碎瓶颈。他还在性能监控和调优方面做着一些工作，使MySQL在多个CPU上更具备伸缩性。Jeremy D. Zawodny和他的两只猫在1999年底从俄亥俄州的西北部搬到了硅谷，这样他就能为Yahoo！工作了——那时他刚好亲眼见证了.com泡沫的幻灭。他在Yahoo！工作了八年半，将MySQL和其余开源技术组合起来应用，找到乏味的、令人兴奋的用处，而它们往往也是很大的用处。近段时间，他从新发掘出了对航行的酷爱。其实，早在2003年年初，他就曾经获得了私人滑翔机飞行员的执照，2005年取得商业飞行员的定级。从那时起，他花了大量的闲暇工夫驾驶滑翔机,翱翔在Hollister、加利福尼亚和Tahoe湖地区上空。他偶然还会驾驶单引擎轻型飞机，和他人独特领有一架Citabria 7KCAB和一架Cessna 182。长期的征询工作能够帮忙他领取航行账单。Jeremy和他可人的妻子及四只猫生存在加州的旧金山湾区。他的博客地址是jeremy.zawodny.com/blog。Arjen Lentz 出世在阿姆斯特丹，但从千禧年以来他和他漂亮的女儿Phoebe、黑猫 Figaro始终生存在澳大利亚的Queensland。Arjen最后是C程序员，在MySQL AB公司(2001-2007)里是第25号职员。在2007年短暂的劳动之后，Arjen创立了Open Query（http://openquery.com.au），该公司致力于在亚太及邻近地区开发和提供数据治理培训和咨询服务。Arjen也常常在讨论会和用户群中发表讲演。在富余的空闲工夫里，Arjen热衷于烹饪、园艺、浏览、露营，以及钻研RepRap。他的博客地址是http://arjen-lentz.livejourna...。Derek J. Balling自1996年以来就始终是Linux系统管理员。他帮助Yahoo!那样的公司和Vassar学院那样的机构建设和保护服务器基础设施，也曾为Perl杂志和其余一些在线杂志撰写文章，并始终为LISA（Large Installation System Administration）会议的编程委员会服务。目前，他作为数据中心经理受雇于Answers.com。当不做与计算机无关的事件时，Derek喜爱和他的妻子Debbie及他们的动物群（四只猫和一只狗）在一起。在博客http://blog.megacity.org上，他也会对以后热点收回评论或写些近来惹恼他的事件。下载地址https://590m.com/file/1876512...

开发时常常会遇到因为删除过sql记录而导致主键ID不间断，在删除记录再新增时，自增的数值并不会占用你删除的值，而是持续在原根底上++。 其实自增编号(id)往往被用作标识记录的唯一性。无需过于在意它的程序和值。如果须要有意义的序号值，倡议另起一个字段，和主键的意义离开配合应用。 不过我这人不一样，尽管用不上主键id从新排序，但就是忍不住整顿下。 这里以一个demo表为例：假如要操作的表名就是demo，冀望针对表中id字段的值进行从新排序，那么接下来须要做的是： 在要操作的表上新建一个字段，用于贮存以后的ID。 alter table demo add old_id int(10) not null;将以后的ID保留到新字段old_id中。 update demo set old_id=id;删除以后表的ID字段(自增主键)。 alter table demo drop id;从新建设ID字段，数据类型可按它原先的来。 alter table demo add id int(10) not null;设置一下这个新ID字段的属性，设置为自增和主键。 alter table demo modify column id int(10) not null auto_increment, add primary key (id);通过下面这步，新的ID字段曾经重新排列了~上面还必须更新一下其它相关联的表，这也就是创立那个old_id的作用了。 update demo as a, 其它相关联的表名 as b set b.aid=a.id where b.aid=a.old_id;实现！当初的文章ID曾经从1开始从新计数了~~如果对你有用的话, 给我一个赞和珍藏吧 , 你的反对对我十分重要

几个问题？Mysql 的框架有几个组件，各个组件有什么作用？Mysql 的server层和存储引擎层各有什么作用？you have an error in your SQL syntax 这个报错是在词法剖析外面还是在语法分析外面？对于表的操作权限是在哪里进行？1 答：mysql有五个组件，别离是：连接器： (客户端和服务端链接，用户名明码的校验）查问缓存：（mysql 8.0之后默认删除此性能）sql语句（key) => 后果 （value) 分析器： 词法剖析和语法分析（词法剖析的后果，语法分析器会依据语法规定，判 断你输出的sql语句是否满足mysql语法。如果你的语句不对，就会收到“you havean error in you SQL syntax"揭示。优化器：优化sql语句，是否有索引，链接形式执行器：判断你对表有没有执行查问的权限，如果没有机返回没有权限的谬误，如下所有（如果在查问缓存中命中缓存，查问也会在优化器调用 Precheck验正权限 2 答：server层包含连接器，查问缓存，分析器（词法语法分析），优化器，执行器等，涵盖了mysql的大多数外围性能，以及所有内置函数（如日期、工夫、数学），所有跨存储引擎的性能都在这一层实现，比方存储过程、触发器、视图等。存储引擎负责数据的存储和提取。其架构模式是插件式的，存储引擎有innodb,myisam,memory。 3 答：这条报错切实分析器中的语法分析报错的。 4 答：执行器，执行器在执行之前会 precheck操作

MySQL启动报错window10上装置了MySQL之前应用都是执行net start mysql启动，执行net stop mysql敞开。 某天开始启动报错“MySQL 服务无奈启动”，“请键入 NET HELPMSG 3523 以取得更多的帮忙”。 如果再执行启动命令会报“服务正在启动或进行中，请稍候片刻后再试一次”。 解决方案这种问题网上有 批改配置文件my.ini删data目录下文件重装MySQL等多种解决办法。前两种计划没能解决我的问题。 至于重装MySQL，据我所知，曾经装置过MySQL的windows电脑第二次装置MySQL，会有很多坑。如果不想折腾，这里有个快捷的方法，你能够试一试。 最简略的解决方案mysqld --console命令MySQL在window下的启动形式有两种： 以管理员权限关上cmd，执行net start mysql。以管理员权限关上cmd，进入MySQL装置目录bin下，执行mysqld --console。第一种启动形式不胜利，能够按上面步骤换第二种形式试试。 第一步杀MySQL残留过程换第二种办法启动之前，先把mysqld过程杀死。执行 tasklist| findstr "mysql" 查看是否有mysqld过程。 如果有mysqld过程，执行 taskkill/f /t /im mysqld.exe 杀死过程 第二步启动MySQL到MySQL装置目录bin下，执行 mysqld --console

通过一个例子看看索引的威力t_user表插入1百万条数据 查找name = user0，耗时213msselect * from t_user where name = 'user0' 减少name字段的索引ALTER TABLE t_user ADD INDEX index_name (name) 再次查找，耗时1ms 真厉害啊，但索引到底是个啥？为什么能够放慢数据库的检索速度呢？ 首先说说MySQL默认引擎InnoDB的根本存储构造，Page(页)* 数据是一条一条记录在页中的，组成一个单向链表。* 多个数据页能够组成一个双向链表。页与记录的关系如下图： 再说说如果没有用索引，数据库是怎么查找记录的？比方:SELECT [列名列表] FROM 表名 WHERE 列名 = xxx; 定位到记录所在的页。从所在的页内中查找相应的记录，这里又分两种状况： 以主键为搜寻条件，在数据页中有对主键列建设页目录，通过主键查找某条记录的时候能够在页目录中应用二分法疾速定位到对应的槽，而后再遍历该槽对应分组中的记录即可疾速找到指定的记录。以其余列为搜寻条件，在数据页中并没有对非主键列建设所谓的页目录，所以咱们无奈通过二分法疾速定位相应的槽。这种状况下只能从最小记录开始顺次遍历单链表中的每条记录，而后比照每条记录是不是合乎搜寻条件。很显然，这种查找的效率是非常低的。不论是依据主键列或者其余列的值进行查找，因为咱们并不能疾速的定位到记录所在的页，所以只能从第一个页沿着双向链表始终往下找，在每一个页中依据咱们上边的查找形式去查找指定的记录。因为要遍历所有的数据页，所以这种形式显然是超级耗时的，如果一个表有一亿条记录，应用这种形式去查找记录那要等到猴年马月能力等到查找后果。 应用索引，放慢了查找速度的起因不必索引查问慢的根本原因是不能疾速的定位到记录所在的页。索引就是应用了B+树这种数据结构，将无序的数据变成了有序的数据，从而放慢了查找速度。能够看到叶子节点存储的是数据记录页，非叶子节点存储是目录项记录页。另外还有的特点： 页内的记录是依照列的大小程序排成一个单向链表。各个寄存用户记录的页也是依据页中记录的列大小程序排成一个双向链表。各个寄存目录项的页也是依据页中记录的列大小程序排成一个双向链表。很显著的是：没有用索引咱们是须要遍历双向链表来定位对应的页，当初通过“目录”就能够很快地定位到对应的页上了！ 一些索引相干知识点汇集和非汇集索引汇集索引就是以主键创立的索引，汇集索引并不需要咱们在MySQL语句中显式的去创立，InnoDB存储引擎会主动的为咱们创立汇集索引，叶子节点记录的是残缺的一条数据，即主键 + 所有列的一条数据非汇集索引就是以非主键创立的索引，非汇集索引在叶子节点存储的是主键和索引列，查问数据时，不能查找到残缺的一条数据，必须再依据主键值去汇集索引生成的B+树中再查找一遍残缺的数据。拿到主键再查找这个过程叫做回表，那为什么咱们还须要一次回表操作呢？间接把残缺的用户记录放到叶子节点不就好了么？因为把残缺的用户记录放到叶子节点是能够不必回表，然而太占中央了呀～相当于每建设一棵B+树都须要把所有的用户记录再都拷贝一遍，这就有点太节约存储空间了。笼罩索引下面的回表操作的起因是非汇集索引须要找到除了主键和索引列以外的字段数据，那么如果非汇集索引蕴含了满足查问语句中字段数据不就不须要回表了吗？就叫做笼罩索引。应用笼罩索引防止了回表的产生缩小了树的搜寻次数，显著晋升性能。 联结索引即对多个列建设索引如key index（a,b)。即对于让B+树依照a和b列的大小进行排序，这个蕴含两层： 先把各个记录和页依照a列进行排序。在记录的a列雷同的状况下，采纳b列进行排序另外 建设联结索引只会建设1棵B+树。为a和b列建设索引会别离以a和b列的大小为排序规定建设2棵B+树。索引最左匹配准则例如索引是key index（a,b,c),能够反对(a),(a,b),(a,c),(a,b,c)组合进行应用索引的查找，但不反对(b),(c),(b,c)进行查找。这就是mysql最左匹配准则，查问条件外面要有联结索引最右边的那个字段才会用到索引。这也对应了上述建设联结索引的B+树时，第一个字段是有序的，后续字段则是无序的。联结索引比对每个列别离建索引更有劣势，因为索引建设得越多就越占磁盘空间，在更新数据的时候速度会更慢。 参考:MySQL的索引数据库两个神器【索引和锁】

写在后面本文次要内容包含，什么是MP4、MP4文件的根本构造、Box的根本构造、常见且重要的box介绍、一般MP4与fMP4的区别、如何通过代码解析MP4文件 等。 写作背景：最近常常答复团队小伙伴对于直播 & 短视频的问题，比方 “flv.js的实现原理”、“为什么设计同学给的mp4文件浏览器里播放不了、但本地能够失常播放”、“MP4兼容性很好，可不可以用来做直播” 等。 在解答的过程中，发现常常波及 MP4 协定的介绍。之前这块有简略理解过并做了笔记，这里略微整顿一下，顺便作为团队参考文档，如有错漏，敬请指出。 什么是MP4首先，介绍下封装格局。多媒体封装格局（也叫容器格局），是指依照肯定的规定，将视频数据、音频数据等，放到一个文件中。常见的 MKV、AVI 以及本文介绍的 MP4 等，都是封装格局。 MP4是最常见的封装格局之一，因为其跨平台的个性而失去广泛应用。MP4文件的后缀为.mp4，基本上支流的播放器、浏览器都反对MP4格局。 MP4文件的格局次要由 MPEG-4 Part 12、MPEG-4 Part 14 两局部进行定义。其中，MPEG-4 Part 12 定义了ISO根底媒体文件格式，用来存储基于工夫的媒体内容。MPEG-4 Part 14 理论定义了MP4文件格式，在MPEG-4 Part 12的根底上进行扩大。对从事直播、音视频相干工作的同学，很有必要理解MP4格局，上面简略介绍下。 MP4文件格式概览MP4文件由多个box组成，每个box存储不同的信息，且box之间是树状构造，如下图所示。 box类型有很多，上面是3个比拟重要的顶层box： ftyp：File Type Box，形容文件听从的MP4标准与版本；moov：Movie Box，媒体的metadata信息，有且仅有一个。mdat：Media Data Box，寄存理论的媒体数据，个别有多个； 尽管box类型有很多，但根本构造都是一样的。下一节会先介绍box的构造，而后再对常见的box进行进一步解说。 下表是常见的box，略微看下有个大抵的印象就好，而后间接跳到下一节。 MP4 Box简介1个box由两局部组成：box header、box body。 box header：box的元数据，比方box type、box size。box body：box的数据局部，理论存储的内容跟box类型无关，比方mdat中body局部存储的媒体数据。box header中，只有type、size是必选字段。当size==0时，存在largesize字段。在局部box中，还存在version、flags字段，这样的box叫做Full Box。当box body中嵌套其余box时，这样的box叫做container box。 Box Header字段定义如下： type：box类型，包含 “预约义类型”、“自定义扩大类型”，占4个字节； 预约义类型：比方ftyp、moov、mdat等预约义好的类型；自定义扩大类型：如果type==uuid，则示意是自定义扩大类型。size（或largesize）随后的16字节，为自定义类型的值（extended_type）size：蕴含box header在内的整个box的大小，单位是字节。当size为0或1时，须要非凡解决： size等于0：box的大小由后续的largesize确定（个别只有装载媒体数据的mdat box会用到largesize）；size等于1：以后box为文件的最初一个box，通常蕴含在mdat box中；largesize：box的大小，占8个字节；extended_type：自定义扩大类型，占16个字节；Box的伪代码如下： ...

如题，本章次要讲下当服务器呈现 ERROR 1040: Too many connections谬误时的一些解决心得。 max_connections查看## 查看最大连接数SHOW VARIABLES LIKE "max_connections";+-----------------+-------+| Variable_name | Value |+-----------------+-------+| max_connections | 512 |+-----------------+-------+## 查看已应用最大连接数SHOW VARIABLES LIKE 'Max_used_connections';+----------------------+-------+| Variable_name | Value |+----------------------+-------+| Max_used_connections | 499 |+----------------------+-------+解决计划这个问题个别有两种解决计划，解决方案非常容易，咱们只须要减少max_connections连接数即可。 减少以后会话的mysql最大连接数SET GLOBAL max_connections = 1000;下面mysql连贯值长期减少到1000，但仅实用于以后会话。一旦咱们重新启动mysql服务或重新启动零碎，该值将重置为默认值。 永恒减少mysql最大连接数为了永恒减少mysql连接数，咱们须要编辑mysql配置文件，即/etc/my.cnf。 sudo vim /etc/my.cnf ## 批改max_connections = 1000保留文件重启MySQL即可失效。 扩多少适合？Max_connextions并不是越大越好的，那么如何配置？ 形式一对于进步MySQL的并发，很大水平取决于内存，官网提供了一个对于innodb的内存计算形式： innodb_buffer_pool_size+ key_buffer_size+ max_connections * (sort_buffer_size + read_buffer_size + binlog_cache_size)+ max_connections * 2MB形式二装置比例扩容： max_used_connections / max_connections * 100% = [85, 90]%最大应用连接数/最大连接数达到了80%～90%区间，就倡议进行优化或者扩容了。 ...

前言： 通过后面文章学习，咱们晓得 binlog 会记录数据库所有执行的 DDL 和 DML 语句（除了数据查问语句select、show等）。留神默认状况下会记录所有库的操作，那么如果咱们有另类需要，比如说只让某个库记录 binglog 或排除某个库记录 binlog ，是否反对此类需要呢？本篇文章咱们一起来看下。 1. binlog_do_db 与 binlog_ignore_db当数据库实例开启 binlog 时，咱们执行 show master status 命令，会看到有 Binlog_Do_DB 与 Binlog_Ignore_DB 选项。 mysql> show master status;+---------------+----------+--------------+------------------+-------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |+---------------+----------+--------------+------------------+-------------------+| binlog.000009 | 282838 | | | |+---------------+----------+--------------+------------------+-------------------+默认状况下，这两个选项为空，那么这两个参数有何作用？是否如同其字面意思一个只让某个库记录 binglog 一个排除某个库记录 binlog 呢？笔者查阅官网文档，简略阐明下这两个参数的作用： binlog_do_db：此参数示意只记录指定数据库的二进制日志，默认全副记录。binlog_ignore_db：此参数示意不记录指定的数据库的二进制日志。这两个参数为互斥关系，个别只抉择其一设置，只能在启动命令行中或配置文件中退出。指定多个数据库要分行写入，举例如下： # 指定 db1 db2 记录binlog[mysqld]binlog_do_db = db1binlog_do_db = db2# 不让 db3 db4 记录binlog[mysqld]binlog_ignore_db = db3binlog_ignore_db = db4此外，这二者参数具体作用与否还与 binlog 格局有关系，在某些状况下 binlog 格局设置为 STATEMENT 或 ROW 会有不同的成果。在理论利用中 binlog_ignore_db 用处更宽泛些，比如说某个库的数据不太重要，为了加重服务器写入压力，咱们可能不让该库记录 binlog 。网上也有文章说设置 binlog_ignore_db 会导致从库同步谬误，那么设置该参数到底有什么成果呢，上面咱们来具体试验下。 ...

并发事务可能呈现问题数据筹备create table city( `id` int unsigned not null auto_increment primary key, `name` varchar(30) not null default '', `score` int not null default 0 )engine=innodb charset=utf8mb4;脏读一个事务读到了另一个未提交事务批改过的数据 session Asession B阐明set session transaction isolation level read uncommitted; 将session A设置为读未提交begin;begin; insert into city(name) values('青岛'); select * from city; 查出了青岛这条记录,脏读不可反复读一个事务读到了另一个已提交事务批改过的数据 session Asession B阐明set session transaction isolation level read committed; 将session A设置为读已提交begin;begin; insert into city(name) values('大连'); select * from city; 没有大连这条记录,脏读解决 commit; select * from city; 查出大连这条记录,不可反复读幻读幻读偏重的方面是某一次的 select 操作失去的后果所表征的数据状态无奈撑持后续的业务操作. ...

一、MySQL自带的压力测试工具 Mysqlslapmysqlslap是mysql自带的基准测试工具,该工具查问数据,语法简略,灵便容易应用.该工具能够模仿多个客户端同时并发的向服务器收回查问更新,给出了性能测试数据而且提供了多种引擎的性能比拟。mysqlslap为mysql性能优化前后提供了直观的验证根据,零碎运维和DBA人员应该把握一些常见的压力测试工具,能力精确的把握线上数据库撑持的用户流量下限及其抗压性等问题。 1、更改其默认的最大连接数 在对MySQL进行压力测试之前，须要更改其默认的最大连接数，如下： [root@mysql ~]# vim /etc/my.cnf................[mysqld]max_connections=1024[root@mysql ~]# systemctl restart mysqld`查看最大连接数`mysql> show variables like 'max_connections';+-----------------+-------+| Variable_name   | Value |+-----------------+-------+| max_connections | 1024  |+-----------------+--------+1 row in set (0.00 sec)进行压力测试： [root@mysql ~]# mysqlslap --defaults-file=/etc/my.cnf --concurrency=100,200 --iterations=1 --number-int-cols=20 --number-char-cols=30 --auto-generate-sql --auto-generate-sql-add-autoincrement --auto-generate-sql-load-type=mixed --engine=myisam,innodb --number-of-queries=2000 -uroot -p123 --verbose上述命令测试阐明：模仿测试两次读写并发，第一次100，第二次200，主动生成SQL脚本，测试表蕴含20个init字段，30个char字段，每次执行2000查问申请。测试引擎别离是myisam，innodb。（上述选项中有很多都是默认值，能够省略，如果想要理解各个选项的解释，能够应用mysqlslap --help进行查问）。 测试后果阐明： Myisam第一次100客户端同时发动增查用0.557/s,第二次200客户端同时发动增查用0.522/sInnodb第一次100客户端同时发动增查用0.256/s,第二次200客户端同时发动增查用0.303/s能够依据理论需要，一点点的加大并发数量进行压力测试。 二、应用第三方sysbench工具进行压力测试1、装置sysbench工具 [root@mysql ~]# yum -y install epel-release #装置第三方epel源[root@mysql ~]# yum -y install sysbench #装置sysbench工具[root@mysql ~]# sysbench --version #确定工具已装置sysbench 1.0.17sysbench能够进行以下测试： CPU 运算性能测试磁盘 IO 性能测试调度程序性能测试内存调配及传输速度测试POSIX 线程性能测试数据库性能测试（OLTP 基准测试，须要通过 /usr/share/sysbench/ 目录中的 Lua 脚本执行，例如 oltp_read_only.lua 脚本执行只读测试）。 sysbench 还能够通过运行命令时指定本人的 Lua 脚本来自定义测试。 2、查看sysbench工具的帮忙选项 [root@mysql ~]# sysbench --helpUsage:sysbench [options]... [testname] [command]Commands implemented by most tests: prepare run cleanup help # 可用的命令，四个General options: # 通用选项--threads=N 要应用的线程数，默认 1 个 [1]--events=N 最大容许的事件个数 [0]--time=N 最大的总执行工夫，以秒为单位 [10]--forced-shutdown=STRING 在 --time 工夫限度达到后，强制敞开之前期待的秒数，默认“off”禁用（number of seconds to wait after the --time limit before forcing shutdown, or 'off' to disable） [off]--thread-stack-size=SIZE 每个线程的堆栈大小 [64K]--rate=N 均匀传输速率。0 则无限度 [0]--report-interval=N 以秒为单位定期报告具备指定距离的两头统计信息 0 禁用两头报告 [0]--report-checkpoints=[LIST,...] 转储残缺的统计信息并在指定的工夫点重置所有计数器。参数是一个逗号分隔的值列表，示意从测试开始通过这个工夫量时必须执行报告检查点（以秒为单位）。报告检查点默认敞开。 []--debug[=on|off] 打印更多 debug 信息 [off]--validate[=on|off] 尽可能执行验证查看 [off]--help[=on|off] 显示帮忙信息并退出 [off]--version[=on|off] 显示版本信息并退出 [off]--config-file=FILENAME 蕴含命令行选项的文件--tx-rate=N 废除，改用 --rate [0]--max-requests=N 废除，改用 --events [0]--max-time=N 废除，改用 --time [0]--num-threads=N 废除，改用 --threads [1]Pseudo-Random Numbers Generator options: # 伪随机数发生器选项--rand-type=STRING random numbers distribution {uniform,gaussian,special,pareto} [special]--rand-spec-iter=N number of iterations used for numbers generation [12]--rand-spec-pct=N percentage of values to be treated as 'special' (for special distribution) [1]--rand-spec-res=N percentage of 'special' values to use (for special distribution) [75]--rand-seed=N seed for random number generator. When 0, the current time is used as a RNG seed. [0]--rand-pareto-h=N parameter h for pareto distribution [0.2]Log options: # 日志选项--verbosity=N verbosity level {5 - debug, 0 - only critical messages} [3]--percentile=N percentile to calculate in latency statistics (1-100). Use the special value of 0 to disable percentile calculations [95]--histogram[=on|off] print latency histogram in report [off]General database options: # 通用的数据库选项--db-driver=STRING 指定要应用的数据库驱动程序 ('help' to get list of available drivers)--db-ps-mode=STRING prepared statements usage mode {auto, disable} [auto]--db-debug[=on|off] print database-specific debug information [off]Compiled-in database drivers: # 內建的数据库驱动程序，默认反对 MySQL 和 PostgreSQLmysql - MySQL driverpgsql - PostgreSQL drivermysql options: # MySQL 数据库专用选项--mysql-host=[LIST,...] MySQL server host [localhost]--mysql-port=[LIST,...] MySQL server port [3306]--mysql-socket=[LIST,...] MySQL socket--mysql-user=STRING MySQL user [sbtest]--mysql-password=STRING MySQL password []--mysql-db=STRING MySQL database name [sbtest]--mysql-ssl[=on|off] use SSL connections, if available in the client library [off]--mysql-ssl-cipher=STRING use specific cipher for SSL connections []--mysql-compression[=on|off] use compression, if available in the client library [off]--mysql-debug[=on|off] trace all client library calls [off]--mysql-ignore-errors=[LIST,...] list of errors to ignore, or "all" [1213,1020,1205]--mysql-dry-run[=on|off] Dry run, pretend that all MySQL client API calls are successful without executing them [off]pgsql options: # PostgreSQL 数据库专用选项--pgsql-host=STRING PostgreSQL server host [localhost]--pgsql-port=N PostgreSQL server port [5432]--pgsql-user=STRING PostgreSQL user [sbtest]--pgsql-password=STRING PostgreSQL password []--pgsql-db=STRING PostgreSQL database name [sbtest]Compiled-in tests: # 內建测试类型fileio - File I/O testcpu - CPU performance testmemory - Memory functions speed testthreads - Threads subsystem performance testmutex - Mutex performance testSee 'sysbench <testname> help' for a list of options for each test.3、sysbench测试MySQL数据库性能 1）筹备测试数据 #查看sysbench自带的lua脚本应用办法[root@mysql ~]# sysbench /usr/share/sysbench/oltp_common.lua help#必须创立sbtest库，sbtest是sysbench默认应用的库名[root@mysql ~]# mysqladmin -uroot -p123 create sbtest;#而后，筹备测试所用的表，这些测试表放在测试库sbtest中。这里应用的lua脚本为/usr/share/sysbench/oltp_common.lua。[root@mysql ~]# sysbench --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-password=123 /usr/share/sysbench/oltp_common.lua --tables=10 --table_size=100000 prepare#其中--tables=10示意创立10个测试表，#--table_size=100000示意每个表中插入10W行数据，#prepare示意这是筹备数的过程。2）确认测试数据以存在 [root@mysql ~]# mysql -uroot -p123 sbtest; #登录到sbtest库mysql> show tables; #查看相应的表+------------------+| Tables_in_sbtest |+------------------+| sbtest1 || sbtest10 || sbtest2 || sbtest3 || sbtest4 || sbtest5 || sbtest6 || sbtest7 || sbtest8 || sbtest9 |+------------------+10 rows in set (0.00 sec)mysql> select count(*) from sbtest1; #随机抉择一个表，确认其有100000条数据+----------+| count(*) |+----------+| 100000 |+----------+1 row in set (0.01 sec)3）数据库测试和后果剖析 略微批改下之前筹备数据的语句，就能够拿来测试了。须要留神的是，之前应用的lua脚本为oltp_common.lua，它是一个通用脚本，是被其它lua脚本调用的，它不能间接拿来测试。 所以，我这里用oltp_read_write.lua脚本来做读、写测试。还有很多其它类型的测试，比方只读测试、只写测试、删除测试、大批量插入测试等等。可找到对应的lua脚本进行调用即可。 #执行测试命令如下：[root@mysql ~]# sysbench --threads=4 --time=20 --report-interval=5 --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-password=123 /usr/share/sysbench/oltp_read_write.lua --tables=10 --table_size=100000 run上述命令返回的后果如下： [root@mysql ~]# sysbench --threads=4 --time=20 --report-interval=5 --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-password=123 /usr/share/sysbench/oltp_read_write.lua --tables=10 --table_size=100000 runsysbench 1.0.17 (using system LuaJIT 2.0.4)Running the test with following options:Number of threads: 4Report intermediate results every 5 second(s)Initializing random number generator from current timeInitializing worker threads...Threads started!#以下是每5秒返回一次的后果，统计的指标包含：# 线程数、tps(每秒事务数)、qps(每秒查问数)、# 每秒的读/写/其它次数、提早、每秒谬误数、每秒重连次数[ 5s ] thds: 4 tps: 1040.21 qps: 20815.65 (r/w/o: 14573.17/4161.25/2081.22) lat (ms,95%): 7.17 err/s: 0.00 reconn/s: 0.00[ 10s ] thds: 4 tps: 1083.34 qps: 21667.15 (r/w/o: 15165.93/4334.55/2166.68) lat (ms,95%): 6.55 err/s: 0.00 reconn/s: 0.00[ 15s ] thds: 4 tps: 1121.57 qps: 22429.09 (r/w/o: 15700.64/4485.30/2243.15) lat (ms,95%): 6.55 err/s: 0.00 reconn/s: 0.00[ 20s ] thds: 4 tps: 1141.69 qps: 22831.98 (r/w/o: 15982.65/4566.16/2283.18) lat (ms,95%): 6.09 err/s: 0.00 reconn/s: 0.00SQL statistics:queries performed:read: 307146 # 执行的读操作数量write: 87756 # 执行的写操作数量other: 43878 # 执行的其它操作数量total: 438780transactions: 21939 (1096.57 per sec.) # 执行事务的均匀速率queries: 438780 (21931.37 per sec.) # 均匀每秒能执行多少次查问ignored errors: 0 (0.00 per sec.)reconnects: 0 (0.00 per sec.)General statistics:total time: 20.0055s # 总耗费工夫total number of events: 21939 # 总申请数量(读、写、其它)Latency (ms):min: 1.39avg: 3.64max: 192.0595th percentile: 6.67 # 采样计算的均匀提早sum: 79964.26Threads fairness:events (avg/stddev): 5484.7500/15.12execution time (avg/stddev): 19.9911/0.004、cpu/io/内存等测试 sysbench内置的几个测试指标如下： [root@mysql ~]# sysbench --help.......... # 省略局部内容Compiled-in tests:fileio - File I/O testcpu - CPU performance testmemory - Memory functions speed testthreads - Threads subsystem performance testmutex - Mutex performance test能够间接help输入测试方法，例如，fileio测试： [root@mysql ~]# sysbench fileio helpsysbench 1.0.17 (using system LuaJIT 2.0.4)fileio options:--file-num=N number of files to create [128]--file-block-size=N block size to use in all IO operations [16384]--file-total-size=SIZE total size of files to create [2G]--file-test-mode=STRING test mode {seqwr, seqrewr, seqrd, rndrd, rndwr, rndrw}--file-io-mode=STRING file operations mode {sync,async,mmap} [sync]--file-async-backlog=N number of asynchronous operatons to queue per thread [128]--file-extra-flags=[LIST,...] list of additional flags to use to open files {sync,dsync,direct} []--file-fsync-freq=N do fsync() after this number of requests (0 - don't use fsync()) [100]--file-fsync-all[=on|off] do fsync() after each write operation [off]--file-fsync-end[=on|off] do fsync() at the end of test [on]--file-fsync-mode=STRING which method to use for synchronization {fsync, fdatasync} [fsync]--file-merged-requests=N merge at most this number of IO requests if possible (0 - don't merge) [0]--file-rw-ratio=N reads/writes ratio for combined test [1.5]1）测试io性能 例如，创立5个文件，总共2G，每个文件大略400M。 [root@mysql ~]# sysbench fileio --file-num=5 --file-total-size=2G prepare[root@mysql ~]# ll -lh test*-rw------- 1 root root 410M May 26 16:05 test_file.0-rw------- 1 root root 410M May 26 16:05 test_file.1-rw------- 1 root root 410M May 26 16:05 test_file.2-rw------- 1 root root 410M May 26 16:05 test_file.3-rw------- 1 root root 410M May 26 16:05 test_file.4而后运行测试： [root@mysql ~]# sysbench --events=5000 --threads=16 fileio --file-num=5 --file-total-size=2G --file-test-mode=rndrw --file-fsync-freq=0 --file-block-size=16384 run返回的后果如下： Running the test with following options:Number of threads: 16Initializing random number generator from current timeExtra file open flags: (none)5 files, 409.6MiB each2GiB total file sizeBlock size 16KiBNumber of IO requests: 5000Read/Write ratio for combined random IO test: 1.50Calling fsync() at the end of test, Enabled.Using synchronous I/O modeDoing random r/w testInitializing worker threads...Threads started!File operations:reads/s: 9899.03writes/s: 6621.38fsyncs/s: 264.33Throughput: # 吞吐量read, MiB/s: 154.66 #示意读带宽written, MiB/s: 103.46 #示意写的带宽General statistics:total time: 0.3014stotal number of events: 5000Latency (ms):min: 0.00avg: 0.81max: 53.5695th percentile: 4.10sum: 4030.48Threads fairness:events (avg/stddev): 312.5000/27.64execution time (avg/stddev): 0.2519/0.022）测试cpu性能 [root@mysql ~]# sysbench cpu --threads=40 --events=10000 --cpu-max-prime=20000 run压测时，还请小心谨慎！！！！ 起源：https://www.toutiao.com/i6843...

前言前段时间遇到了一个Mysql 死锁相干的问题，整顿一下。 问题形容：Mysql 的批改语句仿佛都没有失效，同时应用Mysql GUI 工具编辑字段的值时会弹出异样。 什么是死锁在解决Mysql 死锁的问题之前，还是先来理解一下什么是死锁。 死锁是指两个或两个以上的过程在执行过程中,因抢夺资源而造成的一种相互期待的景象,若无外力作用,它们都将无奈推动上来.此时称零碎处于死锁状态或零碎产生了死锁,这些永远在相互等的过程称为死锁过程。 死锁的体现死锁的具体表现有两种： Mysql 增改语句无奈失常失效应用Mysql GUI 工具编辑字段的值时，会出现异常。如何防止死锁阻止死锁的路径就是防止满足死锁条件的状况产生，为此咱们在开发的过程中须要遵循如下准则： 1.尽量避免并发的执行波及到批改数据的语句。 2.要求每一个事务一次就将所有要应用到的数据全副加锁，否则就不容许执行。 3.预先规定一个加锁程序，所有的事务都必须依照这个程序对数据执行封闭。如不同的过程在事务外部对对象的更新执行程序应尽量保障统一。 查看死锁Mysql 查问是否存在锁表有多种形式，这里只介绍一种最罕用的。 1. 查看正在进行中的事务SELECT * FROM information_schema.INNODB_TRX能够看到 过程id为3175 的事务在锁住了，而另一个id为3173的事务正在执行，然而没有提交事务。 2. 查看正在锁的事务SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS; 3. 查看期待锁的事务SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS; 4. 查问是否锁表SHOW OPEN TABLES where In_use > 0; 在产生死锁时，这几种形式都能够查问到和以后死锁相干的信息。 5. 查看最近死锁的日志show engine innodb status 解除死锁如果须要解除死锁，有一种最简略粗犷的形式，那就是找到过程id之后，间接干掉。 查看以后正在进行中的过程 show processlist// 也能够应用SELECT * FROM information_schema.INNODB_TRX;这两个命令找进去的过程id 是同一个。 杀掉过程对应的过程 id kill id验证（kill后再看是否还有锁） SHOW OPEN TABLES where In_use > 0;参考链接Mysql 查看表和解锁表Mysql 死锁是什么？

一、概述先说论断，如果你的MySQL数据库运行在一个高并发的环境下，那么MySQL8劣势很大，降级到MySQL8是一个很好的抉择；但如果你的MySQL运行环境是低并发的，那么MySQL8劣势并不显著，集体倡议不要当初就降级到MySQL8，能够等一等。 本文针对的是低并发环境下的MySQL8与MySQL5的性能比拟。 1.1 背景依据网上一些应用sysbench做的MySQL8的性能基准测试的后果来看，MySQL8绝对MySQL5的性能劣势更多体现在高并发环境(如连接数达到1024甚至2048)下，单位工夫解决数量(例如InnoDB解决行数或处理事务数量)的极大进步。即，高并发下的TPS指标，MySQL8绝对MySQL5有很大的劣势。 能够参考这篇文章 : MySQL Performance Benchmarking: MySQL 5.7 vs MySQL 8.0但理论的生产环境上，也有很多零碎并未运行在高并发环境下，它们的数据库连接数往往不会超过默认的最大连接数151，它们甚至不须要独立的MySQL服务器。对于这种场景，生产环境上是否有必要将MySQL降级到8呢？ 本文针对MySQL5.7.28与MySQL8.0.22的docker镜像版本，在各自都没有做性能优化配置的根底上，在雷同的宿主机环境下，在雷同的表构造与雷同的数据量下，对它们进行了一些完全相同的，单个连贯上的性能测试，并对其进行数据统计与剖析。 即，本文思考的不是高并发环境下的性能体现，而是低并发环境下，单个连贯上的性能体现。此时次要关注各种SQL操作的耗时和资源耗费。 1.2 单连贯的性能比拟论断对单个连贯的性能测试后果进行统计分析之后，得出以下论断： 因为MySQL8对hash join的反对，对于连贯字段上没有任何索引的多表连贯查问，MySQL8具备压倒性的性能劣势。能够应用倒序索引的话，MySQL8具备肯定性能劣势。在其余场景的性能体现上，如单表读写，多表索引连贯查问等等，MySQL8根本与MySQL5没有太大区别，甚至略有不如。MySQL8对资源的耗费，如CPU和内存，要比MySQL5多一些。1.3 低并发环境下是否降级到MySQL8的倡议对于低并发环境来说，MySQL8对性能的最大晋升来自于哈希连贯的反对。但实际上因为索引的存在，理论能用到哈希连贯的场景并不是那么多。尤其是曾经稳固运行了一段时间的生产环境上，如果连贯字段上齐全没有索引且数据量较大的话，性能问题应该早就裸露进去了；而且MySQL8的版本还在不停迭代降级中，一些性能的兼容性还不是很稳固(有些性能在8.0.x较早的版本里反对，后续更高一点版本又不反对了)。 因而对于低并发的生产环境，集体倡议： 如果没有足够的MySQL运维能力，那么不倡议为了性能晋升而降级MySQL到8.0.x的版本，除非确定生产上有很多无索引的字段作为连贯条件(实际上不可能)。但如果要从其余方面(安全性，NOSQL之类)思考，比方须要应用JSON加强性能，那么能够思考降级。如果有足够的MySQL运维能力，能够思考降级到MySQL8，然而运维须要提供小版本甚至主版本升级的计划与能力，并能继续对MySQL配置进行优化。简而言之一句话，生产上先等等，等到8.1版本当前再看看。 至于开发或者测试环境，能够尝试一下，做一些技术筹备。 1.3 次要性能数据比照本文的性能比拟次要看各种操作的耗时(或者说响应工夫)，以及在操作执行期间的资源(CPU与内存)耗费。 以下耗时统计与资源耗费统计均基于本地测试环境与测试数据，不能代表广泛的性能体现。只能用于雷同环境与数据下Mysql5与8的性能比拟。 1.3.1 耗时比拟对MySQL8与MySQL5别离进行了以下操作： 操作操作阐明mysql8耗时mysql5耗时JDBC连贯-3毫秒2毫秒大表写入100万条记录分批插入，每批1000条30秒+20秒+大表扫描单表100万记录，无条件的全表扫描1秒+1秒+索引查问单表100万记录，一般Btree索引，等值条件查问，命中率1%0.02~0.05秒0.02~0.05秒索引连贯百万记录表与十万记录表连贯，连贯字段是惟一索引33秒+28秒+无索引连贯1百万记录表与一万记录表连贯，连贯字段无索引2秒+半小时左右无索引连贯2百万记录表与100记录表连贯，连贯字段无索引1.5秒+17秒+独立子查问100记录表作为百万记录表的IN条件子查问0.8秒+14秒+关联子查问100记录表作为百万记录表的EXISTS条件子查问0.8秒+18秒+倒序排序百万记录表建设正序倒序混合索引，并应用它排序0.4秒+1.3秒+留神： 各个测试的具体阐明参考后续章节。无索引连贯1，无索引连贯2，独立子查问以及关联子查问中，mysql8劣势显著的起因都是哈希连贯的反对。就是说，这几个测试案例中的表的连贯字段都是没有索引的字段。关联子查问在MySQL8中还多一个半连贯优化，但劣势不显著。500万以上的单表就应该思考分区或分表了，这里不思考这种场景。对于索引连贯与哈希连贯的性能比照，不能一概而论谁性能体现更好，而是取决于具体的表构造与数据量。这个点与本文其实无关，但后续章节也有探讨。1.3.2 资源耗费统计在测试过程中，对CPU与内存耗费进行了简略的统计，后果如下： 我的项目mysql8mysql5批量写入百万数据过程中的CPU使用率(%)9070各种查问过程中的CPU使用率(%)100100mysql容器重启之后内存使用量(M)341.2205.9各种操作之后mysql容器内存应用涨幅(M)130110由此能够得出的初步论断： MySQL8的内存使用量高于MySQL5。写入数据时，MySQL8须要更多的CPU资源。简而言之，MySQL8比MySQL5更耗费CPU与内存资源。 二、性能测试环境本次测试应用docker镜像，在本地启动了两个mysql容器，均没有资源限度，也没有非凡的性能优化配置。 MySQL5版本 : 5.7.28MySQL8版本 : 8.0.22安装文件 : mysql官网提供的docker镜像Docker宿主机OS : Linux Mint 19.1 TessaDocker宿主机CPU : Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz 4 core 8 processDocker宿主机内存 : 32GDocker宿主机磁盘 : SSDMySQL5配置 :[client]default-character-set=utf8mb4[mysqld]character-set-client-handshake = FALSEcharacter-set-server = utf8mb4collation-server = utf8mb4_unicode_citransaction_isolation = READ-COMMITTED[mysql]default-character-set=utf8mb4MySQL8配置 :[mysqld]pid-file = /var/run/mysqld/mysqld.pidsocket = /var/run/mysqld/mysqld.sockdatadir = /var/lib/mysqlsecure-file-priv= NULLdefault_authentication_plugin = mysql_native_passwordtransaction_isolation = READ-COMMITTEDDocker容器资源限度 : 无限度三、测试数据3.1 DDL别离在MySQL5与MySQL8的实例中创立如下数据库与表： ...

当MySQL单表记录数过大时，增删改查性能都会急剧下降，能够参考以下步骤来优化： 单表优化 除非单表数据将来会始终一直上涨，否则不要一开始就思考拆分，拆分会带来逻辑、部署、运维的各种复杂度，个别以整型值为主的表在千万级以下，字符串为主的表在五百万以下是没有太大问题的。而事实上很多时候MySQL单表的性能仍然有不少优化空间，甚至能失常撑持千万级以上的数据量： 字段 尽量应用TINYINT、SMALLINT、MEDIUM_INT作为整数类型而非INT，如果非负则加上UNSIGNEDVARCHAR的长度只调配真正须要的空间应用枚举或整数代替字符串类型尽量应用TIMESTAMP而非DATETIME，单表不要有太多字段，倡议在20以内防止应用NULL字段，很难查问优化且占用额定索引空间用整型来存IP索引 索引并不是越多越好，要依据查问有针对性的创立，思考在WHERE和ORDER BY命令上波及的列建设索引，可依据EXPLAIN来查看是否用了索引还是全表扫描应尽量避免在WHERE子句中对字段进行NULL值判断，否则将导致引擎放弃应用索引而进行全表扫描值散布很稀少的字段不适宜建索引，例如"性别"这种只有两三个值的字段字符字段只建前缀索引字符字段最好不要做主键不必外键，由程序保障束缚尽量不必UNIQUE，由程序保障束缚应用多列索引时主见程序和查问条件保持一致，同时删除不必要的单列索引查问SQL 可通过开启慢查问日志来找出较慢的SQL不做列运算：SELECT id WHERE age + 1 = 10，任何对列的操作都将导致表扫描，它包含数据库教程函数、计算表达式等等，查问时要尽可能将操作移至等号左边sql语句尽可能简略：一条sql只能在一个cpu运算；大语句拆小语句，缩小锁工夫；一条大sql能够堵死整个库不必SELECT *OR改写成IN：OR的效率是n级别，IN的效率是log(n)级别，in的个数倡议管制在200以内不必函数和触发器，在应用程序实现防止%xxx式查问少用JOIN应用同类型进行比拟，比方用’123’和’123’比，123和123比尽量避免在WHERE子句中应用!=或<>操作符，否则将引擎放弃应用索引而进行全表扫描对于间断数值，应用BETWEEN不必IN：SELECT id FROM t WHERE num BETWEEN 1 AND 5列表数据不要拿全表，要应用LIMIT来分页，每页数量也不要太大引擎目前宽泛应用的是MyISAM和InnoDB两种引擎： MyISAMMyISAM引擎是MySQL 5.1及之前版本的默认引擎，它的特点是： 不反对行锁，读取时对须要读到的所有表加锁，写入时则对表加排它锁不反对事务不反对外键不反对解体后的平安复原在表有读取查问的同时，反对往表中插入新纪录反对BLOB和TEXT的前500个字符索引，反对全文索引反对提早更新索引，极大晋升写入性能对于不会进行批改的表，反对压缩表，极大缩小磁盘空间占用InnoDBInnoDB在MySQL 5.5后成为默认索引，它的特点是： 反对行锁，采纳MVCC来反对高并发反对事务反对外键反对解体后的平安复原不反对全文索引总体来讲，MyISAM适宜SELECT密集型的表，而InnoDB适宜INSERT和UPDATE密集型的表 零碎调优参数 能够应用上面几个工具来做基准测试： sysbench：一个模块化，跨平台以及多线程的性能测试工具iibench-mysql：基于 Java 的 MySQL/Percona/MariaDB 索引进行插入性能测试工具tpcc-mysql：Percona开发的TPC-C测试工具具体的调优参数内容较多，具体可参考官网文档，这里介绍一些比拟重要的参数： back_log：back_log值指出在MySQL临时进行答复新申请之前的短时间内多少个申请能够被存在堆栈中。也就是说，如果MySql的连贯数据达到max_connections时，新来的申请将会被存在堆栈中，以期待某一连贯开释资源，该堆栈的数量即back_log，如果期待连贯的数量超过back_log，将不被授予连贯资源。能够从默认的50升至500wait_timeout：数据库连贯闲置工夫，闲置连贯会占用内存资源。能够从默认的8小时减到半小时max_user_connection: 最大连接数，默认为0无下限，最好设一个正当下限thread_concurrency：并发线程数，设为CPU核数的两倍skip_name_resolve：禁止对外部连贯进行DNS解析，打消DNS解析工夫，但须要所有近程主机用IP拜访key_buffer_size：索引块的缓存大小，减少会晋升索引处理速度，对MyISAM表性能影响最大。对于内存4G左右，可设为256M或384M，通过查问show status like ‘key_read%’，保障key_reads / key_read_requests在0.1%以下最好innodb_buffer_pool_size：缓存数据块和索引块，对InnoDB表性能影响最大。通过查问show status like ‘Innodb_buffer_pool_read%’，保障 (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests越高越好innodb_additional_mem_pool_size：InnoDB存储引擎用来存放数据字典信息以及一些外部数据结构的内存空间大小，当数据库对象十分多的时候，适当调整该参数的大小以确保所有数据都能寄存在内存中进步拜访效率，当过小的时候，MySQL会记录Warning信息到数据库的谬误日志中，这时就须要该调整这个参数大小innodb_log_buffer_size：InnoDB存储引擎的事务日志所应用的缓冲区，一般来说不倡议超过32MBquery_cache_size：缓存MySQL中的ResultSet，也就是一条SQL语句执行的后果集，所以仅仅只能针对select语句。当某个表的数据有任何任何变动，都会导致所有援用了该表的select语句在Query Cache中的缓存数据生效。所以，当咱们的数据变动十分频繁的状况下，应用Query Cache可能会得失相当。依据命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))进行调整，个别不倡议太大，256MB可能曾经差不多了，大型的配置型静态数据可适当调大.能够通过命令show status like 'Qcache_%'查看目前零碎Query catch应用大小read_buffer_size：MySql读入缓冲区大小。对表进行程序扫描的申请将调配一个读入缓冲区，MySql会为它调配一段内存缓冲区。如果对表的程序扫描申请十分频繁，能够通过减少该变量值以及内存缓冲区大小进步其性能sort_buffer_size：MySql执行排序应用的缓冲大小。如果想要减少ORDER BY的速度，首先看是否能够让MySQL应用索引而不是额定的排序阶段。如果不能，能够尝试减少sort_buffer_size变量的大小read_rnd_buffer_size：MySql的随机读缓冲区大小。当按任意程序读取行时(例如，依照排序程序)，将调配一个随机读缓存区。进行排序查问时，MySql会首先扫描一遍该缓冲，以防止磁盘搜寻，进步查问速度，如果须要排序大量数据，可适当调高该值。但MySql会为每个客户连贯发放该缓冲空间，所以应尽量适当设置该值，以防止内存开销过大。record_buffer：每个进行一个程序扫描的线程为其扫描的每张表调配这个大小的一个缓冲区。如果你做很多程序扫描，可能想要减少该值thread_cache_size：保留以后没有与连贯关联然而筹备为前面新的连贯服务的线程，能够疾速响应连贯的线程申请而无需创立新的table_cache：相似于thread_cache_size，但用来缓存表文件，对InnoDB成果不大，次要用于MyISAM降级硬件 Scale up，这个不多说了，依据MySQL是CPU密集型还是I/O密集型，通过晋升CPU和内存、应用SSD，都能显著晋升MySQL性能 读写拆散 也是目前罕用的优化，从库读主库写，个别不要采纳双主或多主引入很多复杂性，尽量采纳文中的其余计划来进步性能。同时目前很多拆分的解决方案同时也兼顾思考了读写拆散 缓存 缓存能够产生在这些档次： MySQL外部：在零碎调优参数介绍了相干设置数据拜访层：比方MyBatis针对SQL语句做缓存，而Hibernate能够准确到单个记录，这里缓存的对象次要是长久化对象Persistence Object应用服务层：这里能够通过编程伎俩对缓存做到更精准的管制和更多的实现策略，这里缓存的对象是数据传输对象Data Transfer ObjectWeb层：针对web页面做缓存浏览器客户端：用户端的缓存能够依据理论状况在一个档次或多个档次联合退出缓存。这里重点介绍下服务层的缓存实现，目前次要有两种形式： ...

MySQL 引擎、索引和算法弄懂了 MySQL 的根本 CURD 操作之后，下一个必须把握的常识就是 MySQL 的索引。 我在面试中，常常喜爱针对 MySQL 的常识由浅入深地问上来，理解候选人对 MySQL 常识的理解到了哪一个层级。上一篇文章中的那些常识太根底了，我是不会拿来问的。因而我会问的第一个问题必然是 MySQL 的索引。 对于 MySQL 的索引，我大抵会问上面几个问题： 你晓得 InnoDB 索引所应用的算法是什么吗？为什么 InnoDB 要应用 B+ 树而不是其余的数据结构呢？在 InnoDB 中，是不是必须要有主键？如果建表的时候不指定主键会怎么？InnoDB 的主键和索引有什么区别？要答复这两个问题，咱们须要理解上面几个常识：引擎、索引、树 MySQL 索引的背景常识MySQL 的引擎MySQL 在设计之初，就容许嵌入不同的引擎。数据库的外围算法实际上是由引擎来实现的。晚期 MySQL 数据库有以下三个支流引擎： MyISAM: 这是 MySQL 5.5 之前的默认引擎。因为其不反对事务处理，因而在新的零碎中基本上没什么人用了。InnoDB: 这是 MySQL 5.6 以及之后的默认引擎。如果你不晓得应该选什么引擎的话，选它根本没错。Memory: 这是一个非凡的引擎，该引擎存取的数据，全副放在内存中，不会落入磁盘。因而当数据库宕机或重启后，数据就会失落。自从 Redis 衰亡之后，memory 引擎也式微了。因为新零碎中简直都选用了 InnoDB 引擎，因而下文中如无特地阐明，则指的均为 InnoDB 引擎下的软件原理和行为。 存储系统中的 “页”依照参考资料1 InnoDB 引擎的要害个性包含以下内容： 插入缓冲（Insert Buffer）两次写（Double Write）自适应哈希索引（Adapitve Hash Index）异步 IO（Async IO）刷新临接页（Flush Neighbor Page）能够看到五个个性中，有四个个性是和存储间接相干的。学过计算机组成原理的话就会晓得，计算机存储，依据其与 CPU 的间隔由近到远有以下几个： ...

MySQL数据类型：整数类型： 类型存储所需字节数取值范畴tinyint1-128 ~ 127smallint2-32768 ~ 32767mediumint3-8388608 ~ 8388607int4-2147483648 ~ 2147483647bigint8-2的63次方 ~ 2的63次方-1定点型： 定点数用于准确的示意小数; 应用形式：即 decimal(M,D) 例： salary decimal(5,2)//5称为精度，2称为刻度M 示意总的数字位数D 示意小数点前面数字的位数M的默认取值为10，D默认取值为0。如果创立表时，某字段定义为decimal类型不带任何参数，等同于decimal(10,0)。带一个参数时，D取默认值。浮点型： 浮点数用于近似的示意小数; float ：4个字节，单精度浮点数； double：8个字节，双精度浮点数； 字符串类型： char： 0~255之间的整数，用处，定长字符串； varchar：0~65535之间的整数，用处，变长字符串 tinytext： 0~255，用处，短文本字符串 text：0~65535，用处，长文本数据 mediumtext：0~16777215，用处，中等长度文本数据 longtext： 0~4294967295，用处， 极大文本数据 日期和工夫类型： year：字节数为1，取值范畴为“1901——2155”，格局，YYYY date：字节数为4，取值范畴为“1000-01-01——9999-12-31”，格局，YYYY-MM-DD time：字节数为3，取值范畴为“-838:59:59——838:59:59”，格局， HH:MM:SS datetime：字节数为8，取值范畴为“1000-01-01 00:00:00——9999-12-31 23:59:59”，格局，YYYY-MM-DD HH:MM:SS timestamp：字节数为4，格局，YYYYMMDD HHMMSS

CardinalityCardinality数值示意了该索引字段的反复率水平，数值越大代表反复率越低，PRIMIARY是自增的，可能保障插入/更新数据依照磁盘程序进行，然而id字段因为没有什么可筛选的含意，不能进行筛选查问。 咱们为data_unique_key建设了一个惟一索引，这个属性的值是一些筛选字段的md5值，如果是具体查问某一条数据的话，能够md5后查问data_unique_key为该值，速度很快。 对于反复率十分大的字段，摸索一下为a建设索引是否有必要。a的Cardinality是21b的Cardinality是77c的Cardinality是1305 最左匹配准则ALTER TABLE test ADD INDEX index (a, b, c);假如当初有一张test表，咱们先建设一个联结索引，索引蕴含a,b,c3个字段。咱们建设的索引是3个字段联结的，然而查问的时候只用两个字段进行筛选，也会应用这个索引的前两个字段进行筛选。还是应用两个字段进行筛选，只是用了c而不是b，查问应用了index这个索引然而key_len是202，阐明只用了a的索引局部。这景象是“最左匹配准则”带来的。也就是说要像最大化利用索引，筛选的时候要依据建设索引的字段程序就行查问，如果where等筛选/分组/排序操作能命中索引的局部程序字段，则也会应用这部分程序字段进行索引。SELECT中有索引的字段，优化器会抉择应用索引查问，所以查问进去的后果是以page_name排序的。反之，如果SELECT中没有索引字段，或者只有局部蕴含，或者是查问 * ，都不会应用索引进行查问 a是否有必要成为索引字段SELECT a, e FROM test WHERE a = '2';(这个工夫应该是利用了缓存的根底上的工夫，第一次进行全表查问的工夫是7秒多，同样的sql再次查问就变成了1+秒，试过将query_cache_type和query_cache_size都设置为0，还是这样，有说法是操作系统级别的缓存是无奈限度的。如果一开始就建设索引，并SELECT a FROM test，也是六七秒，所以狐疑查问后都会有缓存，那么以下的工夫都是在这个根底上进行截图) 建设一个联结索引 ALTER TABLE test ADD INDEX index(`a, b, c`);-- SQL1:SELECT a, e FROM test WHERE a = '1' ; -- SQL2:SELECT a, e FROM test WHERE a = '1' AND b = 2; -- SQL3:SELECT a, e FROM test WHERE a = '1' AND data_type = 2 AND c = 'math';发现了只利用索引的一个字段进行查问，查问破费的工夫比全表查问还要慢很多，然而索引字段利用率大，查问破费的工夫就很少了。 ...

假如一个用户管理系统，每个人注册都有一个惟一的手机号，而且业务代码曾经保障了不会写入两个反复的手机号。如果用户管理系统须要依照手机号查姓名，就会执行相似这样的 SQL 语句： select name from users where mobile = '15202124529'; 通常会思考在 mobile 字段上建索引。因为手机号字段绝对较大，通常根本不会把手机号当做主键，那么当初就有两个抉择: 1. 给 id_card 字段创立惟一索引2. 创立一个一般索引如果业务代码曾经保障了不会写入反复的身份证号，那么这两个抉择逻辑上都是正确的。 从性能的角度思考，抉择惟一索引还是一般索引？如图：假如字段 k 上的值都不反复 接下来，就从这两种（ID，k）索引对查问语句和更新语句的性能影响来进行剖析 查问过程假如，执行查问的语句是 select id from T where k=5。这个查问语句在索引树上查找的过程，先是通过 B+ 树从树根开始，按层搜寻到叶子节点，也就是图中右下角的这个数据页，而后能够认为数据页外部通过二分法来定位记录(数据页外部通过有序数组保留节点。数据页之间通过双向链表串接)。 对于一般索引来说，查找到满足条件的第一个记录 (5,500) 后，须要查找下一个记录，直到碰到第一个不满足 k=5 条件的记录。对于惟一索引来说，因为索引定义了唯一性，查找到第一个满足条件的记录后，就会进行持续检索。那么，这个不同带来的性能差距会有多少呢？答案是，微不足道。 起因：除非 Key 的列十分大，有间断多个 Key 占满了一个 page，才会引起一次 page 的 IO，这样才会产生比拟显著的性能差别，从均摊上看，差别简直能够不算。 InnoDB 的数据是按数据页为单位来读写的。也就是说，当须要读一条记录的时候，并不是将这个记录自身从磁盘读出来，而是以页为单位，将其整体读入内存。在 InnoDB 中，每个数据页的大小默认是 16KB。 更新过程为了阐明一般索引和惟一索引对更新语句性能的影响这个问题，须要先介绍一下 change buffer 当须要更新一个数据页时，如果数据页在内存中就间接更新，而如果这个数据页还没有在内存中的话，在不影响数据一致性的前提下： InnoDB 会将这些 更新操作 缓存在 change buffer 中，这样就不须要从磁盘中读入这个数据页了。在下次查问须要拜访这个数据页的时候，将数据页读入内存，而后执行 change buffer 中与这个页无关的操作。    通过这种形式就能保障这个数据逻辑的正确性 须要阐明的是，尽管名字叫作 change buffer，实际上它是能够长久化的数据。也就是说，change buffer 在内存中有拷贝，也会被写入到磁盘上。 ...

大数据归档-冷热数据拆散尽管之前咱们的数据是扩散在不同的分片中，然而与日俱增分片中的数据越来越多，数据迁徙的老本就大大提高，所以能不能将数据进行拆散。 咱们能够将很少应用到的数据，从分片中归档到归档数据库中。 InnoDB 写入慢的起因因为 InnoDB 自身应用的是 BTree 索引，正因为如此，每次写入都须要用 IO 进行索引树的重排。特地是当数据量特地大的时候，效率并不够高。 什么是 TokuDBTokuDB 是一个反对事务的“新”引擎，有着杰出的数据压缩性能，由美国 TokuTek 公司（当初曾经被 Percona 公司收买）研发。领有杰出的数据压缩性能，如果咱们的数据写多读少，而且数据量比拟大，咱们就能够应用 TokuDB，以节俭空间老本，并大幅度降低存储使用量和 IOPS 开销，不过相应的会减少 CPU 的压力。 特点： 高压缩比，高写入性能，（能够达到压缩比 1：12，写入速度是 InnoDB 的 9~20 倍）在线创立索引和字段反对事务反对主从同步装置 TokuDB在之前的文章（一）中独自装置过 percona 数据库，咱们当初不再重新安装 Percona 数据库。 装置 jemalloc 库yum install -y jemalloc批改 my.cnfvim /etc/my.cnf在mysqld_safe节点下减少 malloc-lib。 ……[mysqld_safe]malloc-lib=/usr/lib64/libjemalloc.so.1……而后启动 MySQL 服务。 systemctl restart mysqld开启 Linux 大页内存为了保障 TokuDB 的写入性能，咱们须要敞开 linux 零碎的大页内存治理，默认状况下 linux 的大页内存治理是在系统启动时事后分配内存，零碎运行时不再扭转了。 echo never > /sys/kernel/mm/transparent_hugepage/enabledecho never > /sys/kernel/mm/transparent_hugepage/defrag装置 TokuDB版本必须和 Percona 的版本统一，咱们后面装置的是 Percona5.7，所以此处也须要装置 toku5.7，否则提醒版本抵触。 ...

https://www.jianshu.com/p/09e10b5efa63

https://www.jianshu.com/p/c0c351244c88

docker容器matomo装置docker pull mysql:5.7.25docker pull matomo容器目录配置mkdir -pv /home/[matomodockerfile](http://matomodockerfile/var/www/html)mkdir -pv /home/mysql-matomo5.7.25/data/mkdir -pv /home/mysql-matomo5.7.25/conf/docker mysql5.7.25 的配置文件cat /home/mysql-matomo5.7.25/data/my.cnf      //mysql5.7   的配置文件[client]port = 3306socket = /tmp/mysql.sock[mysqld]server-id = 1port = 3306datadir = /var/lib/mysqltmpdir = /tmpsocket = /tmp/mysql.sockskip-external-lockingskip_name_resolve = 1transaction_isolation = READ-COMMITTEDcharacter-set-server = utf8mb4collation-server = utf8mb4_general_ciinit_connect='SET NAMES utf8mb4'lower_case_table_names = 1max_connections = 400max_connect_errors = 1000explicit_defaults_for_timestamp = truemax_allowed_packet = 128Minteractive_timeout = 1800wait_timeout = 1800tmp_table_size = 134217728max_heap_table_size = 134217728query_cache_size = 0query_cache_type = 0sort_buffer_size = 2097152binlog_cache_size = 524288back_log = 130log_error = error.loglog_queries_not_using_indexes = 1log_throttle_queries_not_using_indexes = 5long_query_time = 8min_examined_row_limit = 100expire_logs_days = 5master_info_repository = TABLErelay_log_info_repository = TABLEinnodb_buffer_pool_size = 1Ginnodb_flush_method = O_DIRECTinnodb_file_format = Barracudainnodb_write_io_threads = 4innodb_read_io_threads = 4innodb_io_capacity = 500innodb_lock_wait_timeout = 30innodb_buffer_pool_dump_pct = 40innodb_print_all_deadlocks = 1[mysqldump]quickmax_allowed_packet = 128M[mysql]no-auto-rehash[myisamchk]key_buffer_size = 20Msort_buffer_size = 256kread_buffer = 2Mwrite_buffer = 2M[mysqlhotcopy]interactive-timeout[mysqld_safe]open-files-limit = 28192容器启动docker run -d -p 3306:3306 -e MYSQL_ROOT_PASSWORD=xxxxxx --privileged=true --restart=always --name mysql-matomo5.7.25 -v /home/mysql-matomo5.7.25/conf/:/etc/mysql/ -v /home/mysql-matomo5.7.25/data/:/var/lib/mysql [docker.io/mysql:5.7.25](http://docker.io/mysql:5.7.25)docker run -d --link mysql-matomo5.7.25:db --restart=always --name matomo -v /home/[matomodockerfile:/var/www/html](http://matomodockerfile/var/www/html) -p 80:80 matomo:latest                    //启动matomo docker ps7ca5d8353500 matomo:latest "/entrypoint.sh apac…" 26 minutes ago Up 26 minutes 0.0.0.0:80->80/tcp matomo51676564dc10 mysql:5.7.25 "docker-entrypoint.s…" 46 hours ago Up 27 minutes 0.0.0.0:3306->3306/tcp, 33060/tcp mysql-matomo5.7.25 ...

问题在 26 问中，咱们看到了如下 SQL 在 MySQL 5.7 中跑得很慢： 咱们还剖析了执行打算改写后的 SQL，通过猜想，减少了 hint 来解决问题： 这一期，咱们通过工具来剖析一下：MySQL 为什么会应用一个低效的执行打算，以致于咱们不得已用 hint 来调优 SQL？ 试验咱们接着应用 26 问中的环境，应用 optimizer trace 工具，察看 MySQL 对 SQL 的优化处理过程。 咱们先调大 optimizer trace 的内存容量（否则 trace 的输入会被截断），而后开启了optimizer trace 性能。 跑完 SQL 后，能够在 INFORMATION_SCHEMA.OPTIMIZER_TRACE 看到 SQL 的优化处理过程： 这会是个微小的 json，咱们将其复制进去，找个 json 的可视化编辑器来剖析一下。 小贴士 如果 MySQL 启动时有配置 --secure-file-priv，那能够用， SELECT TRACE INTO DUMPFILE <filename> FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE;将 trace 导出到文件里，会更不便一些。 这里咱们抉择了一个在线的 json 编辑器，应用起来会不便一点： 能够看到整个优化过程分为 6 个步骤，前两步都跟创立长期表相干，而后是 join 的筹备工作，再是两步 join 优化，最初是 join 的执行。 ...

事务：事务就是一组原子性的SQL查问，或者说一个独立的工作单元。 也就是说，事务内的语句，要么全副执行胜利，要么全副执行失败。 事务的特色：A（atomicity）原子性 C（consistency）一致性 I（isolation） 隔离性 D（durability） 持久性 四种隔离级别READ UNCOMMITTED (未提交读) 在READ UNCOMMITTED 级别，事务中的批改，即便没有提交，对其余事务也都是可见的。事务能够读取未提交的数据，这也被称为脏读(Dirty Read)。这个级别会导致很多问题，从性能上来说，READ UNCOMMITTED 不会比其余的级别好太多，但却不足其余级别的很多益处，除非真的有十分必要的理由，在理论利用中一-般很少应用。 READ COMMITTED (提交读) 大多数数据库系统的默认隔离级别都是READ COMMITTED (但MySQL不是)。READ COMMITTED满足后面提到的隔离性的简略定义:一个事务开始时，只能“看见”曾经提交的事务所做的批改。换句话说，一个事务从开始直到提交之前，所做的任何批改对其余事务都是不可见的。这个级别有时候也叫做不可反复读(nonrepeatableread)，因为两次执行同样的查问，可能会失去不一样的后果。 REPEATABLE READ (可反复读) REPEATABLE READ 解决了脏读的问题。该级别保障了在同一个事务中屡次读取同样记录的后果是统一的。然而实践上，可反复读隔离级别还是无奈解决另外一个幻读(Phantom Read)的问题。所谓幻读，指的是当某个事务在读取某个范畴内的记录时,另外一个事务又在该范畴内插入了新的记录，当之前的事务再次读取该范畴的记录时，会产生幻行(Phantom Row)。InnoDB 和XtraDB存储引擎通过多版本并发管制(MVCC, Multiversion Concurrency Control)解决了幻读的问题。本章稍后会做进一步的探讨。可反复读是MySQL的默认事务隔离级别。 SERIALIZABLE (可串行化) SERIALIZABLE是最高的隔离级别。它通过强制事务串行执行，防止了后面说的幻读的问题。简略来说，SERIALIZABLE 会在读取的每-行数据上都加锁，所以可能导致大量的超时和锁争用的问题。理论利用中也很少用到这个隔离级别，只有在十分须要确保数据的一致性而且能够承受没有并发的状况下，才思考采纳该级别。 死锁：是指两个或多个事务再同一资源上互相占用，并申请锁定对方占用的资源，从而导致恶性循环的景象。当多个事务尝试以不同的程序锁定资源时，就可能产生死锁。 事务日志：应用事务日志，存储引擎再批改表的数据时只须要批改其内存拷贝，再把该批改行为记录到长久在硬盘上的事务日志种，而不必每次都将批改的数据自身长久到磁盘。 应用的是追加的形式，因而写日志的操作是磁盘上一小块区域内的程序I/O，而不像随机I/O须要在磁盘的多个中央挪动磁头，所以采纳事务日志的形式相对来说要快得多。事务日志长久当前，内存中被批改的数据在后盾能够缓缓地刷回到磁盘。目前大多数存储引擎都是这样实现的，咱们通常称之，为预写式日志(Write-Ahead Logging),批改数据须要写两次磁盘。如果数据的批改曾经记录到事务日志并长久化，但数据自身还没有写回磁盘，此时零碎解体，存储引擎在重启时可能主动复原这部分批改的数据。具体的复原形式则视存储引擎而定。

MySQL 数据库集群-PXC 计划（三）什么是基准测试基准测试是针对零碎的一种压力测试，但基准测试不关怀业务逻辑，更加简略、间接、易于测试，不要求数据的真实性和逻辑关系。 基准测试的指标 Sysbench 简介 Sysbench 是一个模块化的、跨平台、多线程基准测试工具，次要用于测试零碎及数据库的性能。它次要包含以下几种形式的测试： CPU 性能（零碎级别）磁盘 IO 性能（零碎级别）调度程序性能（零碎级别）内存调配及传输速度（零碎级别）POSIX 线程性能（零碎级别）数据库性能(OLTP 基准测试)目前 Sysbench 次要反对 MySQL,pgsql,oracle 这 3 种数据库。 装置 Sysbenchcurl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bashyum -y install sysbench装置实现后查看是否装置胜利 sysbench --version Sysbench 根本语法sysbench script [option] [command]option 连贯信息参数 参数名称性能意义--mysql-hostIP 地址--mysql-port端口号--mysql-user用户名--mysql-password明码option 执行参数 参数名称性能意义--oltp-test-mode执行模式(simple、nontrx、complex)--oltp-tables-count测试表的数量--oltp-table-size测试表的记录数--threads并发连接数--time测试执行工夫（秒）--report-interval生成报告单的间隔时间（秒）执行模式： simple： 测试查问 不测试写入nontrx：测试无事务的增删改查complex：测试有事务的增删改查command 命令 命令名称性能意义prepare筹备测试数据run执行测试cleanup革除测试数据筹备测试数据在筹备之前咱们先批改一下haproxy.cfg文件，之前咱们配置的是 MyCat 集群的负载平衡，当初改为某一个分片的 PXC 集群即可。 vim /etc/haproxy/haproxy.cfgserver mysql_1 192.168.3.137:3306 check port 3306 weight 1 maxconn 2000server mysql_1 192.168.3.138:3306 check port 3306 weight 1 maxconn 2000server mysql_1 192.168.3.139:3306 check port 3306 weight 1 maxconn 2000保留之后执行命令重启 ...

一、罕用依赖装置装置mysql和redis，并启动服务，装置办法详见"MySQL与Redis的装置"一文装置python开发包： 执行pip3 install python-devel如果报找不到python-devel，则装置python-dev其中包含了一些用C/Java/C#等编写的python扩大在编译的时候依赖的头文件等信息。装置mysql-devel和mysql-libs：yum install mysql-devel mysql-libs，留神：在centos中这里装置应用的是零碎包管理器yum装置bzip2-devel：yum install bzip2-devel装置git：yum install git二、mysql数据库与权限创立我的项目数据库：create database 名字 charset utf8;创立测试用例数据库：create database test_名字 charset utf8; ，测试用例数据库以test结尾创立超级用户：create user "名字"@"%" identified by "明码"；受权：超级用户领有我的项目数据库和测试用例数据库的所有全新啊 grant all on 数据库名.* to "用户名"@"%";grant all on test_数据库名.* to "用户名"@"%";刷新权限：flush privileges;三、近程连贯pycharm我的项目部署上线是在linux环境中，失常的开发中很多人应用的是mac或者windows零碎，为了可能本机开发代码及时上传到远端服务器中，进步开发效率，须要在pycharm中设置近程连贯 在pycharm中设置远端服务器并连贯。在Tools中找到Development，点击Configration进入配置页面 进入配置页面点击+，抉择SFTP，设置服务器名字 点击SSH configration进行连贯配置，点击+增加配置页面，配置之后测试连贯是否胜利 host为近程服务器ip，端口为22，Authentication type不必变配置失效之后返回STFP配置页面，设置Root path门路，这里设置的是我的项目的上一级目录，例如：我的项目的名字为backstage，上一级目录为testProject，那么这里写/testProject，结尾没有斜杠在Advanced中设置Send keep alive messages each，这里设置为10s设置Mappings页面Development path设置为我的项目的名字，以斜杠结尾，结尾没有斜杠 利用后，设置Python Interpreter 新建SSH Interpreter，抉择曾经创立的近程连贯 Interpreter是近程服务器的中的，不是本地机器的，近程服务器应用pipenv --py获取Python Interpreter；Sync folders中左侧是本地我的项目目录，右侧是近程服务器中的我的项目目录，两者之间做了映射。 新建实现之后抉择并利用在我的项目上点击右键，抉择Sync with Deployed to....，而后抉择对应的近程服务器进入到新的页面，本地目录和近程目录文件比拟，拉取近程文件到本地或者跟新本地批改文件到近程服务器 设置我的项目的run/debug Configrations Python Interpreter：抉择设定好的近程连贯中的InterpreterWorking directory：本地的我的项目门路在log中勾选后两项，我的项目开发中能够看到日志的详细信息 ...

背景插入timestamp类型与datetime类型数据比预计后果早14小时 起因如果说相差8小时不够让人诧异，那相差13小时可能会让很多人摸不着头脑。呈现这个问题的起因是JDBC与MySQL对 “CST” 时区协商不统一。因为CST时区是一个很凌乱的时区，有四种含意： 美国中部工夫 Central Standard Time (USA) UTC-05:00或UTC-06:00澳大利亚中部工夫 Central Standard Time (Australia) UTC+09:30中国规范时 China Standard Time UTC+08:00古巴规范时 Cuba Standard Time UTC-04:00MySQL中，如果time_zone为默认的SYSTEM值，则时区会继承为零碎时区CST，MySQL外部将其认为是UTC+08:00。而jdbc会将CST认为是美国中部工夫，这就导致会相差13小时，如果处在冬令时还会相差14个小时。 解决方案解决此问题的办法也很简略，咱们能够明确指定MySQL数据库的时区，不应用引发误会的CST，能够将time_zone改为'+8:00'，同时jdbc连贯串中也能够减少serverTimezone=Asia/Shanghai。如何防止上述时区问题，可能你心里也有了些办法，简要总结几点如下： 首先保证系统时区精确。jdbc连贯串中指定时区，并与数据库时区统一。time_zone参数倡议设置为'+8:00'，不应用容易误会的CST。各环境数据库实例时区参数放弃雷同。拓展常识设置时区办法1查看时区 show variables like '%time_zone%';设置以后会话时区 set time_zone='+8:00'，只对本次会话无效，会话完结后，生效。设置全局会话时区 set global time_zone='+8:00',永恒无效设置立刻失效 flush privileges设置时区办法2通过批改配置文件，重启mysql后永恒无效https://www.cnblogs.com/jiadi...数据库参数信息：全局参数system_time_zone：零碎时区，在MySQL启动时会查看以后零碎的时区并依据零碎时区设置全局参数system_time_zone的值。 全局参数time_zone：用来设置每个连贯会话的时区，默认为system时，应用全局参数system_time_zone的值。数据库连贯参数：serverTimeZone：此参数设置时会抉择time_zone ,为设置则应用数据库系统时区。 MySQL：datetime与timestamp的区别及应用抉择https://majing.io/posts/10000...参考：https://www.cnblogs.com/gaoga...https://www.cnblogs.com/smile...https://blog.csdn.net/qq_3110...https://www.cnblogs.com/jiadi...https://segmentfault.com/a/11...https://www.zhetao.com/conten...http://www.mamicode.com/info-...https://www.cnblogs.com/july-...https://blog.csdn.net/vae1314...https://blog.csdn.net/weixin_...https://www.cnblogs.com/kunji...

概述通常的观点认为，事务仅与数据库相干。将一堆的SQL语句绑定在一起执行，后果是要么全都执行胜利(都胜利才算胜利),要么全都执行失败(有一个失败就按全失败来解决)! 事务的例子转账，张三(1000元)给李四(1000元)转账100元开启事务张三账户减去100元：update 账户表 set money=money-100 where name='张三'; --900 李四账户上加100元：update 账户表 set money=money+100 where name='李四';--1000完结事务 提交/回滚 个性(1)原子性事务中的所有操作都是一个整体，不能被宰割，要么全副执行胜利,要么全都执行失败。 (2)一致性在事务执行前后的业务数据之和，是保持一致的。 举例转账，张三(1000元)给李四(1000元)转账100元。开启事务张三(1000元)-100元=900元李四(1000元)+100元=1100元完结事务：提交/回滚不论事务最初是提交了，还是回滚了，张三和李四的账户金额之和，在转账前，转账后是保持一致的！ (3)隔离性在事务并发时，多个事务之间是具备隔离性的，在一个事务中看不到另一个事务正在进行的数据状态。 (4)持久性事务提交后，在事务中对数据的更新会长久的保留到数据库中。在事务提交之前，事务中执行的操作，并没有真正的更新到数据库。 举例开始事务张三(1000元)给李四(1000元)转账500元张三(1000元)-500元=500元李四(1000元)-500元=1500元完结事务:提交/回滚在事务提交执行，张三减去500元，以及李四加上500元，其实并没有真正批改张三和李四的账户金额，只是在日志中记录了，未来如果事务提交了，在事务提交后，才会真正的刀数据库中，更新张三账户金额为500元，更新李四账户金额为1500元！ MySQL中的事务1.默认状况下,MySQL中的每一条SQL都是一个事务！2.每次在执行SQL语句之前，会默认开启事务，在执行这条SQL语句之后，会主动提交事务。3.如果须要让两条或者两条以上的SQL语句在一个事务中执行，须要再执行之前开启事务，在最初一条SQL语句执行实现后，立刻完结事务。开启事务：start transaction；完结事务：commit(提交)/rollback(回滚)；如果事务汇总的所有SQL语句都执行胜利了，最初咱们能够提交事务；如果事务中的SQL语句有一条执行失败，就按全副失败来解决，最初咱们会回滚(撤销)事务； 示例演示A账户给B账户转账(1)开启事务start transaction(2)A账户减去100元update acc set money=money-100 where name='A'; -- 900元(3)B账户加上100元upadate acc set money+100 where name='B'; -- 1100元(4)查问A,B的账户金额(在不同的cmd窗口进行查看)select * from acc;(5)将事务回滚(撤销),将事务提交rollback;/commit; 并发读问题多个事务对雷同数据进行操作，这叫做事务并发。在事务并发时，如果没有采取必要的隔离措施，可能会导致各种并发问题，毁坏数据的完整性等。这些问题中，其中三类是读问题，别离是：脏读，不可反复读，幻读。 (1)脏读在一个事务中，读取到另外一个事务为提交更新的数据，称之为脏读。举例A(买家)B(卖家)A转账给B 100元开启事务:A-100=900元B+100=1100元此时没有提交事务。。。B在另外一个事务中查问到账户减少了100元,也就是1100元。因为MySQL默认不容许呈现脏读,所以要想演示脏读景象，必须将mysql的事务隔离级别设置为最低。set tx_isolation = 'read-uncommitted'; (2)不可反复读在一个事务中对同一数据的两次查问后果不统一，是因为另一个事务对该数据进行了批改操作!举例事务一：在事务中查问A账户的余额第一次查问：select * from acc where name='A'; -- 1000第二次查问：select * from acc where name='A'; -- 900事务二:A给B转账100元update acc set money = money-100 where name 'A'...提交事务 (3)幻读在一个事务中对同一张表的两次查问后果不统一，是因为有另一个事务对表进行了插入或者删除操作！举例事务一：第一次：select * from acc where id=3;不存在插入一条id为3的记录：insert into acc value(2,'C',2000);--插入失败第二次:select * from acc where id=3;--已存在事务二：插入了一条id为3的记录：insert into acc value(3,'C',3000);提交了事务 ...

环境：CentOs8零碎一、装置MySQL查看是否装置：mysql:rpm -qa | grep mysql查看MySQL装置源：yum search mysql如果有装置源则应用yum装置，若没有则应用wget http://repo.mysql.com/mysql-c...下载之后应用rpm -ivh 安装包名解压和装置应用yum install mysql-server装置操作命令 启动服务：systemctl start mysqld.service重启服务：systemctl restart mysqld.service敞开服务：systemctl stop mysqld.service查看mysql状态：service mysqld status设置MySQL开机自启动： systemctl enable mysqldsystemctl daemon-reloadCreated symlink /etc/systemd/system/multi-user.target.wants/mysqld.service → /usr/lib/systemd/system/mysqld.service.设置用户和明码 登陆mysql：/var/log目录下应用mysql启动服务批改：ALTER USER '用户名'@'localhost' IDENTIFIED BY '明码';刷新权限：flush privileges;配置文件：/etc/my.conf二、Redis装置(一)、yum装置增加EPEL仓库 sudo yum install epel-release更新yum源：sudo yum update装置：yum install redis操作命令 启动：systemctl start redis重启：systemctl restart redis敞开：systemctl stop redis查看状态：systemctl status redis开启自启动：systemctl enable redis批改配置文件：/etc/redis.conf 容许近程连贯：正文掉bind 127.0.0.1启用明码：找到# requirepass foobared，去掉正文，把foobared换成本人的明码重启服务登陆：redis-cli -h 127.0.0.1 -p 6379 -a '明码'(二)、源码装置装置、编译wget http://download.redis.io/releases/redis-6.0.8.tar.gz tar xzf redis-6.0.8.tar.gz cd redis-6.0.8 make批改配置文件(同上)启动服务：redis-server重启服务登陆：redis-cli -h 127.0.0.1 -p 6379 -a '明码'

话说有一文章表article，存储文章的增加文章的工夫是add_time字段，该字段为int(5)类型的，现须要查问明天增加的文章总数并且依照工夫从大到小排序，则查问语句如下： 02 03 1 select * from `article` where date_format(from_UNIXTIME(`add_time`),'%Y-%m-%d') = date_format(now(),'%Y-%m-%d'); 04 或者： 05 06 1 select * from `article` where to_days(date_format(from_UNIXTIME(`add_time`),'%Y-%m-%d')) = to_days(now()); 07 假如以上表的add_time字段的存储类型是DATETIME类型或者TIMESTAMP类型，则查问语句也可按如下写法： 08 09 查问明天的信息记录： 10 11 1 select * from `article` where to_days(`add_time`) = to_days(now()); 12 查问昨天的信息记录： 13 14 1 select * from `article` where to_days(now()) – to_days(`add_time`) <= 1; 15 查问近7天的信息记录： 16 17 1 select * from `article` where date_sub(curdate(), INTERVAL 7 DAY) <= date(`add_time`); 18 查问近30天的信息记录： 19 20 1 select * from `article` where date_sub(curdate(), INTERVAL 30 DAY) <= date(`add_time`); 21 查问本月的信息记录： 22 23 1 select * from `article` where date_format(`add_time`, ‘%Y%m') = date_format(curdate() , ‘%Y%m'); 24 查问上一月的信息记录： 25 26 1 select * from `article` where period_diff(date_format(now() , ‘%Y%m') , date_format(`add_time`, ‘%Y%m')) =1; 27 对下面的SQL语句中的几个函数做一下剖析： 28 29 （1）to_days 30 31 就像它的名字一样，它是将具体的某一个日期或工夫字符串转换到某一天所对应的unix工夫戳，如： 32 33 01 mysql> select to_days('2010-11-22 14:39:51'); 34 02 +--------------------------------+ 35 03 | to_days('2010-11-22 14:39:51') |36 04 +--------------------------------+37 05 | 734463 |38 06 +--------------------------------+39 07 40 08 mysql> select to_days('2010-11-23 14:39:51'); 41 09 +--------------------------------+42 10 | to_days('2010-11-23 14:39:51') |43 11 +--------------------------------+44 12 | 734464 |45 13 +--------------------------------+46 能够看出22日与23日的差异就是，转换之后的数减少了1，这个粒度的查问是比拟毛糙的，有时可能不能满足咱们的查问要求，那么就须要应用细粒度的查询方法str_to_date函数了，上面将剖析这个函数的用法。 47 48 揭示： 49 50 （1）to_days() 不用于阳历呈现(1582)前的值，起因是当日历扭转时，遗失的日期不会被思考在内。因而对于1582 年之前的日期(或者在其它地区为下一年 ), 该函数的结果实不牢靠的。 51 52 （2）MySQL"日期和工夫类型"中的规定是将日期中的二位数年份值转化为四位。因而对于'1997-10-07'和'97-10-07'将被视为同样的日期: 53 54 1 mysql> select to_days('1997-10-07'), to_days('97-10-07'); 55 2 56 3 -> 729669, 72966957 （2）str_to_date 58 59 这个函数能够把字符串工夫齐全的翻译过去，如： 60 61 1 mysql> select str_to_date("2010-11-23 14:39:51",'%Y-%m-%d %H:%i:%s'); 62 2 63 3 +--------------------------------------------------------+64 4 | str_to_date("2010-11-23 14:39:51",'%Y-%m-%d %H:%i:%s') |65 5 +--------------------------------------------------------+66 6 | 2010-11-23 14:39:51 |67 7 +--------------------------------------------------------+68 具体案例操作如下： 69 70 1 select str_to_date(article.`add_time`,'%Y-%m-%d %H:%i:%s') 71 2 from article 72 3 where str_to_date(article.`add_time`,'%Y-%m-%d %H:%i:%s')>='2012-06-28 08:00:00' and str_to_date(article.`add_time`,'%Y-%m-%d %H:%i:%s')<='2012-06-28 09:59:59';[](javascript:void(0); "复制代码")[](javascript:void(0); "复制代码")查问明天 select * from 表名 where to_days(工夫字段名) = to_days(now()); 昨天 SELECT * FROM 表名 WHERE TO_DAYS( NOW( ) ) – TO_DAYS( 工夫字段名) <= 1 7天 SELECT * FROM 表名 where DATE_SUB(CURDATE(), INTERVAL 7 DAY) <= date(工夫字段名) 近30天 SELECT * FROM 表名 where DATE_SUB(CURDATE(), INTERVAL 30 DAY) <= date(工夫字段名) 本月 SELECT * FROM 表名 WHERE DATE_FORMAT( 工夫字段名, ‘%Y%m’ ) = DATE_FORMAT( CURDATE( ) , ‘%Y%m’ ) 上一月 SELECT * FROM 表名 WHERE PERIOD_DIFF( date_format( now( ) , ‘%Y%m’ ) , date_format( 工夫字段名, ‘%Y%m’ ) ) =1 同时，再附上 一个 mysql官网的相干document#查问本季度数据 select * from `ht_invoice_information` where QUARTER(create_date)=QUARTER(now());#查问上季度数据 select * from `ht_invoice_information` where QUARTER(create_date)=QUARTER(DATE_SUB(now(),interval 1 QUARTER));#查问本年数据 select * from `ht_invoice_information` where YEAR(create_date)=YEAR(NOW());#查问上年数据 select * from `ht_invoice_information` where year(create_date)=year(date_sub(now(),interval 1 year)); 查问以后这周的数据 SELECT name,submittime FROM enterprise WHERE YEARWEEK(date_format(submittime,'%Y-%m-%d')) = YEARWEEK(now());查问上周的数据SELECT name,submittime FROM enterprise WHERE YEARWEEK(date_format(submittime,'%Y-%m-%d')) = YEARWEEK(now())-1;查问以后月份的数据 select name,submittime from enterprise where date_format(submittime,'%Y-%m')=date_format(now(),'%Y-%m')查问间隔以后当初6个月的数据 select name,submittime from enterprise where submittime between date_sub(now(),interval 6 month) and now();查问上个月的数据 select name,submittime from enterprise where date_format(submittime,'%Y-%m')=date_format(DATE_SUB(curdate(), INTERVAL 1 MONTH),'%Y-%m') select * from ` user ` where DATE_FORMAT(pudate, ' %Y%m ' ) = DATE_FORMAT(CURDATE(), ' %Y%m ' ) ; select * from user where WEEKOFYEAR(FROM_UNIXTIME(pudate,'%y-%m-%d')) = WEEKOFYEAR(now()) select * from user where MONTH (FROM_UNIXTIME(pudate, ' %y-%m-%d ' )) = MONTH (now()) select * from [ user ] where YEAR (FROM_UNIXTIME(pudate, ' %y-%m-%d ' )) = YEAR (now())and MONTH (FROM_UNIXTIME(pudate, ' %y-%m-%d ' )) = MONTH (now()) select * from [ user ] where pudate between 上月最初一天and 下月第一天 where date(regdate) = curdate(); select * from test where year(regdate)=year(now()) and month(regdate)=month(now()) and day(regdate)=day(now())SELECT date( c_instime ) ,curdate( )FROM `t_score`WHERE 1 LIMIT 0 , 30

注释在传统的后盾管理系统外面常常会须要展现多级菜单关系，明天咱们来学一下如何应用一条SQL语句展现多级菜单。 当初咱们有一张corpinfo单位表，外面有一个belong字段指向下级单位，首先来看一下当初表里有什么数据： SELECT uid,ubelong FROM corpinfo 当初是相似上面这样的一个三级菜单，uid为1的是咱们的顶级菜单，ubelog为0。 当初咱们想实现传入一个 uid ，把以后 uid 和其下级单位的 uid 都展现进去，当然咱们能够应用代码或者网上常见的存储过程来实现，然而明天咱们用一条SQL语句来实现该成果： 先来看看咱们的SQL语句 SELECT DATA.uid FROM( SELECT @ids AS _ids, ( SELECT @ids := GROUP_CONCAT(uid) FROM corpinfo WHERE FIND_IN_SET(ubelong, @ids) ) AS cids, @l := @l+1 AS level FROM corpinfo, (SELECT @ids := (参数) , @l := 0 ) b WHERE @ids IS NOT NULL ) ID, corpinfo DATAWHERE FIND_IN_SET(DATA.uid, ID._ids)ORDER BY level,uid看下执行后果： ...

前言： 随着互联网技术的一直倒退， MySQL 相干生态也越来越欠缺，越来越多的工具涌现进去。一些公司或集体纷纷开源出一些不错的工具，本篇文章次要介绍几款 MySQL 相干实用工具。揭示下，这里并不介绍 Navicat 等这类图形化操作工具哦。 1. SQL 审核 web 工具SQL 审核与执行，可能是各个公司或团队比拟困扰的事件。若没有平台工具反对，只能通过人工的形式来解决，效率低且品质没方法保障。为了标准操作，提高效率，大多数团队可能会本人开发或引入开源工具。这里介绍两款开源收费的 web 端 SQL 审核平台。 Yearning 我的项目地址：https://github.com/cookieY/Yearning我的项目简介：https://guide.yearning.io/Yearning 是一款可满足大部分公司 SQL 审核需要的 web 端可视化 SQL 审核平台。在实现惯例的 sql 审核性能外还增加了诸如数据查问等一系列便捷的性能。 次要性能： 自动化SQL语句审核，可对SQL进行自动检测并执行。DDL/DML语句执行后主动生成回滚语句。审核/查问 审计性能。反对LDAP登录/钉钉及邮件音讯推送。反对自定义审核工作流。反对细粒度权限调配。长处： 颜值高，应用晦涩。局部审核规定可自定义。部署简略，依赖项少。功能丰富，既能审核执行SQL又能查问。作者在继续保护，有社区反对。Archery 我的项目地址：https://github.com/hhyo/Archery应用文档：https://archerydms.com/Archery 定位于 SQL 审核查问平台，旨在晋升 DBA 的工作效率，反对多数据库的 SQL 上线和查问，同时反对丰盛的 MySQL 运维性能，所有性能都兼容手机端操作。 次要性能： 集成 SQL 查问、审核、执行、备份。权限辨别明确，审核执行拆散。SQL 工单主动审批、高危语句驳回。疾速上线其余实例。慢日志治理、SQL 优化等运维性能。反对会话治理及参数配置。可集成其余工具插件。长处： 除 MySQL 外，还反对多种支流数据库。性能更加丰盛，真正做到一平台多用。具备 SQL 优化、慢日志治理等运维性能，对 DBA 更加敌对。基于 Python 及 Django，利于二次开发革新。对于 Yearning 和 Archery ，两者各有优缺点吧，都是优良的开源工具。Yearning 只实用于 MySQL ，部署简略，性能清晰明了，上手容易。Archery 反对多种数据库，部署略微简单些，性能更加丰盛，反对诸多高级运维性能。没有哪个更好，只有哪个更适合。 ...

MySQL 数据库集群-PXC 计划（二）集群状态信息PXC 集群信息能够分为队列信息、复制信息、流控信息、事务信息、状态信息。这些信息能够通过 SQL 查问到。每种信息的具体意义能够在官网查看。 show status like '%wsrep%';复制信息 举例说明几个重要的信息： 状态形容wsrep_replicated被其余节点复制的次数wsrep_replicated_bytes被其余节点复制的数据次数wsrep_received从其余节点处收到的写入申请总数wsrep_received_bytes从其余节点处收到的写入数据总数wsrep_last_applied同步利用次数wsrep_last_committed事务提交次数队列信息队列是一种很好的缓存机制，如果 PXC 正在满负荷工作，没有线程去执行数据的同步，同步申请会缓存到队列中，而后闲暇线程从队列中取出工作，执行同步的申请，有了队列 PXC 就能用大量的线程应答刹时大量的同步申请。 状态形容wsrep_local_send_queue发送队列的长度（刹时同步的申请数量）wsrep_local_send_queue_max发送队列的最大长度wsrep_local_send_queue_min发送队列的最小长度wsrep_local_send_queue_avg发送队列的均匀长度wsrep_local_recv_queue接管队列的长度wsrep_local_recv_queue_max接管队列的最大长度wsrep_local_recv_queue_min接管队列的最小长度wsrep_local_recv_queue_avg接管队列的均匀长度当发送队列的均匀长度(wsrep_local_send_queue_avg)值很大，发送队列的长度(wsrep_local_send_queue)也很大的时候，阐明 PXC 集群同步数据的速度曾经很慢了，队列里边积压了大量的同步申请，这个时候就要检查一下网速是不是失常，或者同步的线程数量是不是太少。 当接管队列的均匀长度(wsrep_local_recv_queue_avg)值很大，接管队列的长度(wsrep_local_recv_queue)也很大的时候，这阐明本地没有足够的线程去执行长久化的操作，减少线程就能够解决这个问题。 流量管制信息流量管制就是 PXC 集群在同步速度较慢的状况下，为了防止同步速度跟不上写入速度而推出的一种限速机制，就是限度数据的写入，直到同步队列的长度变小，同步速度变快为止，才会解除流量管制。流量管制的结果很重大，而且一个很小的操作就会引发流量管制。 状态阐明wsrep_flow_control_paused_ns流控暂停状态下破费的总工夫(纳秒)wsrep_flow_control_paused流量管制暂停工夫的占比(0~1)wsrep_flow_control_sent发送的流控暂停事件的数量wsrep_flow_control_recv接管的流控暂停事件的数量wsrep_flow_control_interval流量管制的上限和下限。下限是队列中容许的最大申请数。如果队列达到下限，则回绝新的申请。当解决现有申请时，队列会缩小，一旦达到上限，将再次容许新的申请wsrep_flow_control_status流量管制状态 OFF:敞开 0N: 开启流控的次要起因节点之间同步的速度慢，队列积压了大量的申请，这才是流控的次要起因。 流控解决办法： 改善网速，进步带宽，更换交换机，千兆网卡更换成万兆网卡减少线程，线程多了执行的速度也就快了。队列里边就不会积压大量的申请晋升硬件性能，比方降级 CPU，内存以及更换光纤硬盘等等都能够进步写入速度第一项和第三项属于更换硬件的办法，次要说一下第二个办法减少线程数晋升同步速度。在 PXC 的配置文件加上wsrep_slave_threads参数。代表的是本地执行队列的线程数量，个别这个数是 CPU 线程数的 1-1.5 倍。比方服务器 CPU 是 8 核 16 线程的，这里就能够写 16-24 就能够。 wsrep_slave_threads=16节点与集群的状态信息 状态阐明wsrep_local_state_comment节点状态wsrep_cluster_status集群状态(Primary：失常状态、Non-Primary：呈现了脑裂申请、Disconnected：不能提供服务,呈现宕机)wsrep_connected节点是否连贯到集群wsrep_ready集群是否失常工作wsrep_cluster_size节点数量wsrep_desync_count延时节点数量wsrep_incoming_addresses集群节点 IP 地址事务相干信息状态阐明wsrep_cert_deps_distance事务执行并发数wsrep_apply_oooe接管队列中事务的占比wsrep_apply_oool接管队列中事务乱序执行的频率wsrep_apply_window接管队列中事务的均匀数量wsrep_commit_oooe发送队列中事务的占比wsrep_commit_oool无任何意义,不存在本地的乱序提交wsrep_commit_window发送队列中事务的均匀数量PXC 节点的平安下线操作节点用什么命令启动，就用对应的敞开命令去敞开。 主节点的治理命令（第一个启动的 PXC 节点） systemctl start mysql@bootstrap.service systemctl stop mysql@bootstrap.service systemctl restart mysql@bootstrap.service非主节点的治理命令（非第一个启动的 PXC 节点）service mysql startservice mysql stopservice mysql restart如果最初敞开的 PXC 节点是平安退出的，那么下次启动要最先启动这个节点，而且要以主节点启动。如果最初敞开的 PXC 节点不是平安退出的，那么要先批改/var/lib/mysql/grastate.dat 文件，把其中的safe_to_bootstrap属性值设置为 1，再依照主节点启动。意外下线局部节点平安下线节点不会让剩下的节点宕机，如果节点意外退出，集群的规模不会放大，意外退出的节点超过半数，比方三个节点意外退出了 2 个节点，那么剩下的节点就不可能读写了。其余节点依照一般节点启动上线即可复原 pxc 集群。 ...

MySQL 数据库集群-PXC 计划（二）集群状态信息PXC 集群信息能够分为队列信息、复制信息、流控信息、事务信息、状态信息。这些信息能够通过 SQL 查问到。每种信息的具体意义能够在官网查看。 show status like '%wsrep%';复制信息 举例说明几个重要的信息： 状态形容wsrep_replicated被其余节点复制的次数wsrep_replicated_bytes被其余节点复制的数据次数wsrep_received从其余节点处收到的写入申请总数wsrep_received_bytes从其余节点处收到的写入数据总数wsrep_last_applied同步利用次数wsrep_last_committed事务提交次数队列信息队列是一种很好的缓存机制，如果 PXC 正在满负荷工作，没有线程去执行数据的同步，同步申请会缓存到队列中，而后闲暇线程从队列中取出工作，执行同步的申请，有了队列 PXC 就能用大量的线程应答刹时大量的同步申请。 状态形容wsrep_local_send_queue发送队列的长度（刹时同步的申请数量）wsrep_local_send_queue_max发送队列的最大长度wsrep_local_send_queue_min发送队列的最小长度wsrep_local_send_queue_avg发送队列的均匀长度wsrep_local_recv_queue接管队列的长度wsrep_local_recv_queue_max接管队列的最大长度wsrep_local_recv_queue_min接管队列的最小长度wsrep_local_recv_queue_avg接管队列的均匀长度当发送队列的均匀长度(wsrep_local_send_queue_avg)值很大，发送队列的长度(wsrep_local_send_queue)也很大的时候，阐明 PXC 集群同步数据的速度曾经很慢了，队列里边积压了大量的同步申请，这个时候就要检查一下网速是不是失常，或者同步的线程数量是不是太少。 当接管队列的均匀长度(wsrep_local_recv_queue_avg)值很大，接管队列的长度(wsrep_local_recv_queue)也很大的时候，这阐明本地没有足够的线程去执行长久化的操作，减少线程就能够解决这个问题。 流量管制信息流量管制就是 PXC 集群在同步速度较慢的状况下，为了防止同步速度跟不上写入速度而推出的一种限速机制，就是限度数据的写入，直到同步队列的长度变小，同步速度变快为止，才会解除流量管制。流量管制的结果很重大，而且一个很小的操作就会引发流量管制。 状态阐明wsrep_flow_control_paused_ns流控暂停状态下破费的总工夫(纳秒)wsrep_flow_control_paused流量管制暂停工夫的占比(0~1)wsrep_flow_control_sent发送的流控暂停事件的数量wsrep_flow_control_recv接管的流控暂停事件的数量wsrep_flow_control_interval流量管制的上限和下限。下限是队列中容许的最大申请数。如果队列达到下限，则回绝新的申请。当解决现有申请时，队列会缩小，一旦达到上限，将再次容许新的申请wsrep_flow_control_status流量管制状态 OFF:敞开 0N: 开启流控的次要起因节点之间同步的速度慢，队列积压了大量的申请，这才是流控的次要起因。 流控解决办法： 改善网速，进步带宽，更换交换机，千兆网卡更换成万兆网卡减少线程，线程多了执行的速度也就快了。队列里边就不会积压大量的申请晋升硬件性能，比方降级 CPU，内存以及更换光纤硬盘等等都能够进步写入速度第一项和第三项属于更换硬件的办法，次要说一下第二个办法减少线程数晋升同步速度。在 PXC 的配置文件加上wsrep_slave_threads参数。代表的是本地执行队列的线程数量，个别这个数是 CPU 线程数的 1-1.5 倍。比方服务器 CPU 是 8 核 16 线程的，这里就能够写 16-24 就能够。 wsrep_slave_threads=16节点与集群的状态信息 状态阐明wsrep_local_state_comment节点状态wsrep_cluster_status集群状态(Primary：失常状态、Non-Primary：呈现了脑裂申请、Disconnected：不能提供服务,呈现宕机)wsrep_connected节点是否连贯到集群wsrep_ready集群是否失常工作wsrep_cluster_size节点数量wsrep_desync_count延时节点数量wsrep_incoming_addresses集群节点 IP 地址事务相干信息状态阐明wsrep_cert_deps_distance事务执行并发数wsrep_apply_oooe接管队列中事务的占比wsrep_apply_oool接管队列中事务乱序执行的频率wsrep_apply_window接管队列中事务的均匀数量wsrep_commit_oooe发送队列中事务的占比wsrep_commit_oool无任何意义,不存在本地的乱序提交wsrep_commit_window发送队列中事务的均匀数量PXC 节点的平安下线操作节点用什么命令启动，就用对应的敞开命令去敞开。 主节点的治理命令（第一个启动的 PXC 节点） systemctl start mysql@bootstrap.service systemctl stop mysql@bootstrap.service systemctl restart mysql@bootstrap.service非主节点的治理命令（非第一个启动的 PXC 节点）service mysql startservice mysql stopservice mysql restart如果最初敞开的 PXC 节点是平安退出的，那么下次启动要最先启动这个节点，而且要以主节点启动。如果最初敞开的 PXC 节点不是平安退出的，那么要先批改/var/lib/mysql/grastate.dat 文件，把其中的safe_to_bootstrap属性值设置为 1，再依照主节点启动。意外下线局部节点平安下线节点不会让剩下的节点宕机，如果节点意外退出，集群的规模不会放大，意外退出的节点超过半数，比方三个节点意外退出了 2 个节点，那么剩下的节点就不可能读写了。其余节点依照一般节点启动上线即可复原 pxc 集群。 ...

MySQL 数据库集群-PXC 计划（二）集群状态信息PXC 集群信息能够分为队列信息、复制信息、流控信息、事务信息、状态信息。这些信息能够通过 SQL 查问到。每种信息的具体意义能够在官网查看。 show status like '%wsrep%';复制信息 举例说明几个重要的信息： 状态形容wsrep_replicated被其余节点复制的次数wsrep_replicated_bytes被其余节点复制的数据次数wsrep_received从其余节点处收到的写入申请总数wsrep_received_bytes从其余节点处收到的写入数据总数wsrep_last_applied同步利用次数wsrep_last_committed事务提交次数队列信息队列是一种很好的缓存机制，如果 PXC 正在满负荷工作，没有线程去执行数据的同步，同步申请会缓存到队列中，而后闲暇线程从队列中取出工作，执行同步的申请，有了队列 PXC 就能用大量的线程应答刹时大量的同步申请。 状态形容wsrep_local_send_queue发送队列的长度（刹时同步的申请数量）wsrep_local_send_queue_max发送队列的最大长度wsrep_local_send_queue_min发送队列的最小长度wsrep_local_send_queue_avg发送队列的均匀长度wsrep_local_recv_queue接管队列的长度wsrep_local_recv_queue_max接管队列的最大长度wsrep_local_recv_queue_min接管队列的最小长度wsrep_local_recv_queue_avg接管队列的均匀长度当发送队列的均匀长度(wsrep_local_send_queue_avg)值很大，发送队列的长度(wsrep_local_send_queue)也很大的时候，阐明 PXC 集群同步数据的速度曾经很慢了，队列里边积压了大量的同步申请，这个时候就要检查一下网速是不是失常，或者同步的线程数量是不是太少。 当接管队列的均匀长度(wsrep_local_recv_queue_avg)值很大，接管队列的长度(wsrep_local_recv_queue)也很大的时候，这阐明本地没有足够的线程去执行长久化的操作，减少线程就能够解决这个问题。 流量管制信息流量管制就是 PXC 集群在同步速度较慢的状况下，为了防止同步速度跟不上写入速度而推出的一种限速机制，就是限度数据的写入，直到同步队列的长度变小，同步速度变快为止，才会解除流量管制。流量管制的结果很重大，而且一个很小的操作就会引发流量管制。 状态阐明wsrep_flow_control_paused_ns流控暂停状态下破费的总工夫(纳秒)wsrep_flow_control_paused流量管制暂停工夫的占比(0~1)wsrep_flow_control_sent发送的流控暂停事件的数量wsrep_flow_control_recv接管的流控暂停事件的数量wsrep_flow_control_interval流量管制的上限和下限。下限是队列中容许的最大申请数。如果队列达到下限，则回绝新的申请。当解决现有申请时，队列会缩小，一旦达到上限，将再次容许新的申请wsrep_flow_control_status流量管制状态 OFF:敞开 0N: 开启流控的次要起因节点之间同步的速度慢，队列积压了大量的申请，这才是流控的次要起因。 流控解决办法： 改善网速，进步带宽，更换交换机，千兆网卡更换成万兆网卡减少线程，线程多了执行的速度也就快了。队列里边就不会积压大量的申请晋升硬件性能，比方降级 CPU，内存以及更换光纤硬盘等等都能够进步写入速度第一项和第三项属于更换硬件的办法，次要说一下第二个办法减少线程数晋升同步速度。在 PXC 的配置文件加上wsrep_slave_threads参数。代表的是本地执行队列的线程数量，个别这个数是 CPU 线程数的 1-1.5 倍。比方服务器 CPU 是 8 核 16 线程的，这里就能够写 16-24 就能够。 wsrep_slave_threads=16节点与集群的状态信息 状态阐明wsrep_local_state_comment节点状态wsrep_cluster_status集群状态(Primary：失常状态、Non-Primary：呈现了脑裂申请、Disconnected：不能提供服务,呈现宕机)wsrep_connected节点是否连贯到集群wsrep_ready集群是否失常工作wsrep_cluster_size节点数量wsrep_desync_count延时节点数量wsrep_incoming_addresses集群节点 IP 地址事务相干信息状态阐明wsrep_cert_deps_distance事务执行并发数wsrep_apply_oooe接管队列中事务的占比wsrep_apply_oool接管队列中事务乱序执行的频率wsrep_apply_window接管队列中事务的均匀数量wsrep_commit_oooe发送队列中事务的占比wsrep_commit_oool无任何意义,不存在本地的乱序提交wsrep_commit_window发送队列中事务的均匀数量PXC 节点的平安下线操作节点用什么命令启动，就用对应的敞开命令去敞开。 主节点的治理命令（第一个启动的 PXC 节点） systemctl start mysql@bootstrap.service systemctl stop mysql@bootstrap.service systemctl restart mysql@bootstrap.service非主节点的治理命令（非第一个启动的 PXC 节点）service mysql startservice mysql stopservice mysql restart如果最初敞开的 PXC 节点是平安退出的，那么下次启动要最先启动这个节点，而且要以主节点启动。如果最初敞开的 PXC 节点不是平安退出的，那么要先批改/var/lib/mysql/grastate.dat 文件，把其中的safe_to_bootstrap属性值设置为 1，再依照主节点启动。意外下线局部节点平安下线节点不会让剩下的节点宕机，如果节点意外退出，集群的规模不会放大，意外退出的节点超过半数，比方三个节点意外退出了 2 个节点，那么剩下的节点就不可能读写了。其余节点依照一般节点启动上线即可复原 pxc 集群。 ...

一、案例分享1.1 问题形容 大查问长时间执行无奈开释DML读锁，后续同步主库的DDL操作获取DML写锁资源被阻塞期待，导致后续同步主库的操作沉积，主从提早增长重大。从同步提早的监控来看，提早从17:11开始，17:51:59进行kill大查问操作，直到17:53倡议业务方将大查问kill掉后才完结。 1.2 解决流程 1、当接管到只读实例的同步提早告警后，登录到RDS的治理控制台查看实例以后会话执行状况，判断只读实例以后负载压力。从以后会话截图能够看到，会话并无显著沉积，然而有两个执行工夫很久的大查问操作。 2、17:11提早开始，17:51 kill大查问，17:53主从提早复原。咱们仍须要排查这个期间主实例和只读实例的运行状况，剖析造成主从提早的具体起因 3、对主实例的排查 1）查看提早期间主库是否有一些批处理/大事务操作，主库业务业务申请上涨或者有批量的更新操作。对此，咱们次要察看主实例的QPS/TPS监控、MySQL_COMDML和日志读写的监控指标。 从以上截图中能够看到，主库TPS在主从提早期间并没有显著的上涨，阐明期间主库业务压力失常；主库MySQL_COMDML和日志读写在主从提早期间也没有显著的上涨，阐明期间主库也没有执行一些批量更新的大事务操作。 2）查看提早期间主库是否有执行耗费较大的DDL操作。在RDS中若开启了审计日志，咱们能够通过工夫以及操作类型进行过滤排查 通过对审计日志的搜寻，咱们搜查到一条对视图定义进行alter的操作，该alter操作仅仅执行了2.32ms，其资源耗费自身并不大。 4、对只读实例的排查 1）查看提早期间只读实例是否有较大负载压力，从只读实例提早期间的会话执行状况以及资源耗费能够晓得，提早期间只读实例并无较大负载压力 2）从只读实例的QPS/TPS监控中能够看到，17:51kill掉大查问后只读实例的TPS异样上涨，17:53TPS恢复正常，提早复原。阐明17:51～17:53期间只读实例在大量利用主库传输过去的binlog日志，复原主从复制提早。 5、捕获提早期间会话中的异常现象，大查问长时间执行未完结，执行explain操作显示为MDL锁期待，联合咱们在主库审计日志中搜寻到的alter操作，咱们能够推断造成主从提早的起因可能是只读实例大查问阻塞了从主库传输过去的Alter操作，导致后续提早始终上涨，并在咱们kill掉大查问后复原。 6、为了印证咱们的猜测，咱们通过审计日志把相干操作的工夫线进行梳理 只读实例view_order_logistics_new相干的大查问执行了3602s还未执行完，始终持有表的DML读锁，不影响表的失常读写操作17:10 主库执行了ALTER ALGORITHM=UNDEFINED DEFINER=super_sha_prd_db@% SQL SECURITY DEFINER VIEW view_order_logistics_new 的操作只读实例view_order_logistics_new的大查问仍在执行中，此时主库执行alter操作传输到只读实例，alter操作须要的DML写锁与大查问持有的DML读锁抵触alter操作无奈获取到DML写锁从而开始期待锁资源，从主控传输过去的binlog也被阻塞，主从提早开始上涨17:51:59 只读实例kill掉了view_order_logistics_new的大查问，只读实例TPS上涨，只读实例开始利用alter操作之后的所有binlog日志17:53:08 只读实例TPS复原，利用提早期间的binlog结束，主从复制恢复正常更多技术信息请查看云掣官网https://www.dtstack.com/dtsmart/

MySQL 数据库集群-PXC 计划（一）什么是 PXCPXC 是一套 MySQL 高可用集群解决方案，与传统的基于主从复制模式的集群架构相比 PXC 最突出特点就是解决了诟病已久的数据复制提早问题，基本上能够达到实时同步。而且节点与节点之间，他们互相的关系是对等的。PXC 最关注的是数据的一致性，看待事物的行为时，要么在所有节点上执行，要么都不执行，它的实现机制决定了它看待一致性的行为十分严格，这也能十分完满的保障 MySQL 集群的数据一致性； PXC 的特点齐全兼容 MySQL。同步复制，事务要么在所有节点提交或不提交。多主复制，能够在任意节点进行写操作。在从服务器上并行利用事件，真正意义上的并行复制。节点主动配置，数据一致性，不再是异步复制。故障切换：因为反对多点写入，所以在呈现数据库故障时能够很容易的进行故障切换。主动节点克隆：在新增节点或停机保护时，增量数据或根底数据不须要人工手动备份提供，galera cluster 会主动拉取在线节点数据，集群最终会变为统一。PXC 的优缺点长处： 服务高可用。数据同步复制(并发复制)，简直无提早。多个可同时读写节点，可实现写扩大，不过最好当时进行分库分表，让各个节点别离写不同的表或者库，防止让 galera 解决数据抵触。新节点能够主动部署，部署操作简略。数据严格一致性，尤其适宜电商类利用。齐全兼容 MySQL。毛病： 复制只反对InnoDB 引擎，其余存储引擎的更改不复制。写入效率取决于节点中最弱的一台，因为 PXC 集群采纳的是强一致性准则，一个更改操作在所有节点都胜利才算执行胜利。所有表都要有主键。不反对 LOCK TABLE 等显式锁操作。锁抵触、死锁问题绝对更多。PXC 集群节点越多，数据同步的速度就越慢。 PXC 与 Replication 的区别ReplicationPXC数据同步是单向的，master 负责写，而后异步复制给 slave；如果 slave 写入数据，不会复制给 master数据同步时双向的，任何一个 mysql 节点写入数据，都会同步到集群中其它的节点异步复制，从和主无奈保证数据的一致性同步复制，事务在所有集群节点要么同时提交，要么同时不提交PXC 罕用端口3306：数据库对外服务的端口号。4444：申请 SST 的端口。4567：组成员之间进行沟通的一个端口号。4568：用于传输 IST。SST(State Snapshot Transfer): 全量传输IST(Incremental state Transfer):增量传输MySQL 衍生版抉择 MariaDB 起初 MySQL 之父 Monty 在 1979 年写下 MySQL 的第一行代码，起初逐步创立起 MySQL 公司，后将其以 10 亿美金卖给 Sun，后果 Sun 又把 MySQL 转手卖给 Oracle，Monty 愤而出奔，以 MySQL5.5 为根底发明了 MariaDB 数据库，这样就诞生出了 MySQL 分支里知名度最高的一个衍生版。 ...

数据库操作CREATE DATABASE 数据库名字 创立数据库USE 数据库名字抉择数据库show tables 显示所有表drop database 数据库名字删除数据库表操作CREATE TABLE 表名(字段 类型,字段 类型) 创立表show create table 表名 显示表的创立语句和详细信息desc 表名 显示表的构造DROP TABLE 表名 删除表truncate table 表名 清空表alter table 表名 add 字段 类型 增加表字段alter table 表名 add 字段 类型 after 表字段 增加表字段，并且插入指定字段地位前面alter table 表名 add 字段 类型 first 增加表字段，并插入最后面alter table 表名 modify 字段 新类型 批改字段类型alter table 表名 change 原字段名字 新字段名字 新类型; 批改字段名字并且批改类型alter table 表名 drop column 字段; 删除表字段alter table 旧表名 rename 新表名 批改表名数据操作条件查问whereSELECT * from t_doctor WHERE doctor_name = "布隆";order by 排序，默认升序（asc）, 降序(高到低)desc 分组GROUP BY分组可能不是特地好了解，我独自举例解释下： 如果有一张护士表，和工作表，护士小姐姐的工作是要随访本人负责的病人，1个护士小姐姐负责多个病人，工作表中存着所有护士小姐姐，执行的所有工作。当初查一下,每个护士小姐姐，各自做了多少次工作<!--依据nurse_id分组,并且统计数量 -->SELECT nurse_id,count(*) as tatal FROM t_visit_task GROUP BY nurse_id ORDER BY tatal desc;with ROLLUP 表明是否对分类聚合后的后果进行再汇总<!--除了晓得每个护士小姐姐执行了多少次工作，还要统计所有护士小姐姐工作总数-->SELECT nurse_id,count(*) as tatal FROM t_visit_task GROUP BY nurse_id WITH ROLLUP;含糊查问like<!--查问doctor_name中蕴含张的所有行-->SELECT * from t_doctor WHERE doctor_name LIKE "%张%";in查问SELECT * FROM t_visit_task WHERE nurse_id in ("1126cf7f-d31e-43f1-a2dd-05b37873f99b","8ce40555-4b62-498b-8e39-af4abb18abfd");<!--如果是where=-->SELECT * FROM t_visit_task WHERE nurse_id = "1126cf7f-d31e-43f1-a2dd-05b37873f99b" OR nurse_id = "8ce40555-4b62-498b-8e39-af4abb18abfd"insert into 表名(字段1,字段2) values(值1,值2),(值1,值2) 插入数据 update 表名 set 字段1="新值",字段2="新值" where 字段='xxx'更新数据，应用update肯定肯定要跟着条件,否则同一字段全副数据都被更改delete from 表名 where 字段="xx"; 删除数据，肯定要加条件，不然全删union 和 union all 对多个select查问进去的数据后果进行合并展现（去除重复部分），union all不去反复 ...

作者：姚远专一于 Oracle、MySQL 数据库多年，Oracle 10G 和 12C OCM，MySQL 5.6，5.7，8.0 OCP。当初鼎甲科技任技术顾问，为共事和客户提供数据库培训和技术支持服务。本文起源：原创投稿*爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。景象一线的工程师反映了一个奇怪的景象，刚刚从 MySQL 官网上下载了一个 MySQL 5.7.31。装置实现后，发现应用任何明码都能登陆 MySQL，批改明码也不论用，重新启动 MySQL 也不能解决。 剖析狐疑应用了 --skip-grant-tables 应用 mysqld --print-defaults 查看，没有发现。查看登陆用户，都是 root@localhost，阐明和 proxy user 没有关系。 mysql> select user(),current_user();+----------------+----------------+| user() | current_user() |+----------------+----------------+| root@localhost | root@localhost |+----------------+----------------+1 row in set (0.01 sec)应用 mysql --print-defaults 查看客户端是否设置默认的用户和明码，没有发现。查看数据库中的用户和明码的相干字段： mysql> select user,host,authentication_string from mysql.user;+------------------+-----------+------------------------------------------------------------------------+| user | host | authentication_string |+------------------+-----------+------------------------------------------------------------------------+| lisi | % | *52BCD17AD903BEC378139B11966C9B91AC4DED7C || mysql.session | localhost | *THISISNOTAVALIDPASSWORDTHATCANBEUSEDHERE || mysql.sys | localhost | *THISISNOTAVALIDPASSWORDTHATCANBEUSEDHERE || root | localhost | *1840214DE27E4E262F5D981E13317691BA886B76 |+------------------+-----------+------------------------------------------------------------------------+5 rows in set (0.01 sec)发现所有都失常，再查看 plugin 字段，发现只有 root 用户是 auth_socket ，其它的用户都是 mysql_native_password，问题可能就出在这儿。 ...

1.优化COUNT()查问首先咱们先回顾以下聚合函数COUNT()的一些用法。简略的将，COUNT()函数的用法有两种，一种是统计表的行数，用法如下： mysql> SELECT COUNT() FROM user;第二种用法就是统计一个具体的数据列的非空值的数量： mysql> SELECT COUNT(age) FROM user;简略的优化：当咱们应用COUNT()计算数据表的行数的时候，大多数存储引擎都不会去残缺的遍历一个表来失去他的行数，而是能够利用存储引擎的个性来间接失去这个值。（这建设在没有where条件的COUNT(\)语句中）。因而咱们能够利用这个特质优化以下状况的查问： mysql> SELECT COUNT(*) FROM user WHERE age > 25;如果咱们假如总共有10000个数据，而上述的查问语句须要查问9000行，这显然是一个效率很差的后果，因而能够将查问转化为： mysql> SELECT (SELECT COUNT(*) FROM user) - COUNT(*) FROM user WHERE age <= 25;下面这个转换看似将一次查问变成了两次，然而实际上取得全表的count十分的快，而取得age<=25的数据只须要查问1000行，这显然比间接查问age>25须要查问9000行来的快得多。 应用近似值有时候咱们在工程与我的项目中应用COUNT()函数，可能并不是须要一个精确的数量值，而只是想晓得以后数据库数据的规模。例如当下想晓得网站的沉闷用户的数量，这往往只须要晓得数据的量级，例如是100000量级还是1000000量级，而对于低位的具体数字就显得不是那么的重要了。因而咱们能够在COUNT()语句后面应用EXPLAIN关键字，EXPLAIN关键字会解析SQL语句，并返回一个大抵的查问行数的估算值，留神此时并不需要执行真正的查问，因而老本很低。 2.优化关联查问确保ON或USING子句中的列有索引，创立索引的时候就须要思考到关联的程序。确保所有GROUP BY和ORDER BY中的表达式只波及到一个表中的列。3.优化子查问对于子查问的优化咱们给出的最重要的倡议就是尽可能应用关联查问代替子查问。 4.优化GROUP BY()语句通常对GROUP BY的分组要求，咱们往往是借助索引来进行优化。因为索引其实在创立的时候就曾经默认的帮忙咱们将该列的数据进行了依照肯定法则的分组，因而当咱们能够预感将会对某一个数据列应用GROUP BY语句的时候，能够在创立时在该列上增加上索引。同样的在多个表的关联查问中，咱们如果想要的失去分组的成果，最好对一个表上的标识列进行分组。 5.优化UNION查问如果不是的确须要服务器打消反复的行，否则就肯定要应用UNION ALL。如果没有ALL关键字，MySQL会给长期表加上一个DISTINCT选项，这会导致对整个表进行数据的唯一性查看，这样做的代价十分高。事实上，即便有ALL关键字，MySQL仍会应用长期表存储后果，再读出，然而没有唯一性查看将会大大降低查找代价。

MySQL是开源的关系型数据库系统。复制(Replication)是从一台MySQL数据库服务器（主服务器master）复制数据到另一个服务器（从服务器slave）的一个过程。 配置主服务器（Master）1、编辑数据库配置文件my.cnf,个别在/etc/目录下。 # 编辑 my.cnfvi /etc/my.cnf# 新增以下内容server-id=211 # 惟一idlog-bin=mysql-bin #启用二进制日志binlog-do-db=aaa-te #要同步的mstest数据库,要同步多个数据库，就多加几个replicate-db-db=数据库名binlog-ignore-db=information_schema #要疏忽的数据库replicate-ignore-db=mysql #要疏忽的数据库replicate-ignore-db=performance_schemareplicate-ignore-db=sys配置从服务器（Slave）# 编辑 my.cnfvi /etc/my.cnf# 新增以下内容server-id=211 #id 惟一，不能与主服务器雷同log-bin=mysql-bin #启用二进制日志而后重启 Mysql (主从都重启) service mysqld restart设置登录 mysql（主机）mysql -uroot -p赋予从库权限帐号，容许用户在主库上读取日志，赋予 192.168.1.2 也就是 Slave 机器有 File 权限，只赋予 Slave 机器有 File 权限还不行，还要给它 REPLICATION SLAVE 的权限才能够。 在 Master 数据库命令行中输出： GRANT FILE ON *.* TO 'root'@'192.168.1.2' IDENTIFIED BY 'mysql password';GRANT REPLICATION SLAVE ON *.* TO 'root'@'192.168.1.2' IDENTIFIED BY 'mysql password';FLUSH PRIVILEGES;注：这里应用的仍是 root 用户作为同步的时候应用到的用户，能够本人设定。 ...

哈希索引基于哈希表实现，只有准确匹配索引所有列的查问才无效。 在MySQL中只有Memory引擎显示反对哈希索引，也是memory引擎表的默认索引类型。memory引擎是反对非惟一哈希索引的。如果多个列的哈希值雷同，索引会以链表 的形式寄存多个记录指针道同一个哈希条目中。 举个粒子: create table testhash(fname varchar(50) not null,lname varchar(50) not null,key using hash(fname))engine=memory;数据库中的数据：mysql> select * from testhash;+--------+-----------+| fname | lname |+--------+-----------+| Baron | Schwartz || Arjen | Lentz || Peter | Zaitsev || Vadim | Tkachenko |+--------+-----------+4 rows in set (0.00 sec)假如f() 为哈希函数，f(fname) 的返回值是其哈希值，对应槽位。槽位是按顺序排列的。每个槽位上的值指向数据。（构造能够了解为 jdk 1.7 中的hashmap的数据结构，一个数组和链表的模式） ERROR 1054 (42S22): Unknown column 'lane' in 'field list'mysql> select lname from testhash where fname ='Peter';+---------+| lname |+---------+| Zaitsev |+---------+1 row in set (0.00 sec)查找的过程是是先计算'Peter'的哈希值，并应用改值寻找对应的记录指针，也就是计算f('Peter')，失去其哈希值为 3468 ，而后在对应的槽位上找到记录指针，找到对应行上的数据，最初一步是比拟查找的值是否为'Peter' ，以确保就是要查找的行。 ...

前言最近敌人小王正在找工作，而后有一个面试官问他知不知道 “查问SQL具体的执行流程” 。小王说不晓得呀，而后面试官间接对小王说：小伙子 耗子尾汁(好自为之) ，怎么连这么简略的都不晓得呢？ 小王听后脱口而出：哼！面试官你 不讲武德 ，不按套路出牌呀，你应该问问索引相干的常识呀，这个我倍分明。 在听完小王形容后，本人也在脑海中搜了搜这个知识点，可怜的是我的知识库里也没找到相干内容，而后就去面壁思过了，随后本文就诞生了。留神 ：本文次要以 MySql 为例；说到了MySql了，而后再唠叨下当初应用非常广泛的MySql的姊妹数据库 MariaDB 。 MariaDB 是个什么东东呢？MySql被Oracle收买后，MySql的创始人放心MySql数据库倒退的将来(开发迟缓、关闭、可能会被闭源)，于是创立了一个分支MariaDB，默认应用全新的Maria存储引擎，它是原来Mysql中的 MyISAM 存储引擎的升级版。 本文主线：①、MySql的整体架构形容； ②、Server层各节点形容； ③、InnoDB存储引擎形容； MySql架构形容咱啥也先不说，先贴上一张摘抄自网上的大图： 下面这张图形容的清不清晰呢？不清晰，那别着急，咱再贴一张： Server服务层形容：通过下面的架构图能够得悉，Server层中次要由 连接器、查问缓存、解析器/分析器、优化器、执行器 几局部组成的，上面将次要形容下这几局部。连接器客户端想要对数据库进行操作时，前提是与数据库建设好连贯；而连接器就是用来负责跟客户端建设连贯、获取权限、维持和治理连贯的。连贯形式：MySQL既反对短连贯，也反对长连贯。短连贯就是操作结束后，马上close关掉。 长连贯能够放弃关上，缩小服务端创立和开释连贯的耗费，前面的程序拜访的时候还能够应用这个连贯。 个别咱们会在连接池中应用长连贯。 长连贯应用时的注意事项：客户端与服务器建设长连贯，默认无效工夫是 8小时 ，超过8小时MySql服务器就会将连贯断开了，那么客户端再次申请的话，就会报 连贯已断开的问题 ； 并且放弃长连贯会耗费内存。长时间不流动的连贯，MySQL服务器会断开。那这个8小时的超时工夫怎么查看呢？ -- 非交互式超时工夫，如 JDBC 程序show global variables like 'wait_timeout'; -- 交互式超时工夫，如数据库工具show global variables like' interactive_timeout'; 执行后失去下图后果：默认都是28800秒，8小时 。 个别我的项目中应用的连接池中的连贯都是长连贯的；（例如：druid、c3p0、dbcp等）举个例子，阐明下长连贯超时断开导致的理论问题：某个敌人的公司有个管理系统，这个零碎应用的时Mysql,然而他最近遇到了一个问题：就是零碎明明前天是好用的，然而第二天去到公司后就打不开了，只有将零碎重启就好了，一时间不晓得什么起因，什么鬼嘛，苦恼？ 最初通过查看日志才发现是连接池中的连贯都断开了，因为从前天到第二天下班这之间隔得工夫超过了8小时了。唉，这么个小知识点导致好几天的困惑，切实不该呀，还是常识把握的不全面呀。好了，当初也找到问题起因了，然而它该怎么解决呢？ 长连贯超时断开的解决方案：①、定期断开长连贯。应用一段时间，或者程序外面判断执行过一个占用内存的大查问后，断开连接，之后要查问再重连。 ②、如果你用的是 MySQL 5.7 或更新版本，能够在每次执行一个比拟大的操作后，通过执行 mysql_reset_connection 来从新初始化连贯资源。这个过程不须要重连和从新做权限验证，然而会将连贯复原到刚刚创立完时的状态。 查问缓存MySQL缓存是默认敞开的，也就是说不举荐应用缓存，为什么呢？MySql为什么默认不开启缓存呢？次要是因为它的应用场景限度的： ①、先说下缓存中数据存储格局：key（sql语句）-value（数据值）；所以如果SQL语句（key）只有存在一点不同之处就会间接进行数据库查问了； ②、因为表中的数据不是变化无穷的，大多数是常常变动的，而当数据库中的数据变动了，那么相应的与此表相干的缓存数据就须要移除掉； 须要留神的是， MySQL 8.0 版本间接将查问缓存的整块性能删掉了，也就是说8.0开始彻底没有这个性能了。分析器分析器的工作次要是对要执行的SQL语句进行解析，最终失去形象语法书，而后再应用预处理器判断形象语法树中的表是否存在，如果存在的话，在接着判断select投影列字段是否在表中存在等。词法剖析词法剖析用于将SQL拆解为不可再分的原子符号，称为Token。并依据不同数据库方言所提供的字典，将其归类为关键字，表达式，字面量和操作符。语法分析语法分析就是依据词法剖析拆解进去的Token（原子符号）将SQL语句转换为形象语法树。上面就间接举例说明，看一个SQL它的形象语法书到底长神魔样：SQL语句： ...

B-Tree 索引不同的存储引擎也可能应用不同的存储构造，i如，NDB集群存储引擎外部实现应用了T-Tree构造存储这种索引，即便其名字是BTREE；InnoDB应用的是B+Tree。 B-Tree通常一位这所有的值都是按顺序存储的，并且每一个叶子页道根的间隔雷同。下图大抵反馈了InnoDB索引是如何工作的。 为什么mysql索引要应用B+树，而不是B树，红黑树看完下面的文章就能够了解为何B-Tree索引可能快速访问数据了。因为存储引擎不再须要进行全表扫描获取须要的数据，叶子节点蕴含了所有元素信息，每一个叶子节点指针都指向下一个节点，所以很适宜查找范畴数据。 索引对多个值进行排列的根据是CREATE TABLE 语句中定义索引时的程序。 那么，索引排序的规定就是依照 last_name ,first_name ,dob 的程序来的。 能够应用 B-Tree 索引的查问类型B-Tree索引实用于全键值、键值范畴或键前缀查找。键前缀查找只是用于依据最左前缀查找。 举个粒子： CREATE TABLE People ( last_name VARCHAR ( 50 ) NOT NULL, first_name VARCHAR ( 50 ) NOT NULL, dob date NOT NULL, gender enum ( 'm', 'f' ) NOT NULL,KEY ( last_name, first_name, dob ) );这个表的索引如下： type后果 type后果值从好到坏顺次是： system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL ...

Mysql8以上反对递归查问了 1.结构表DROP TABLE IF EXISTS `t_area`;CREATE TABLE `t_area` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` char(64) NOT NULL DEFAULT 0 COMMENT '名称', `p_id` int(11) NOT NULL DEFAULT 0 COMMENT '父id', PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT='test';insert into t_area (id,name, p_id) VALUES (1,'中国',0),(2,'广西省',1),(3,'广东省',1),(4,'广州市',3),(5,'深圳市',3),(6,'白云区',4),(7,'越秀区',4),(8,'福田区',5),(9,'南山区',5);2.递归查问sqlwith recursive t as( select * from t_area where id=3 union all select c.* from t_area c join t on c.p_id = t.id)select *from t;3.实测 ...

明天给大家出个外网拜访内网畅捷通软件的教程。置信大家都晓得，在没有公网ip的状况下，咱们是没方法在外网拜访内网的利用的；这时候应该怎么办？ 咱们明天就用闪库内网穿透来解决这一问题：闪库内网穿透是最近在应用的一款比较稳定的内网映射软件，它是一个无需服务器，无需设置路由器的即可实现在外网拜访内网的软件；反对所有基于TCP、UDP协定的利用及协定，包含HTTP、SSH、SMTP、GIT、MYSQL等等；应用教程如下： 工具：闪库内网穿透 利用场景：外网拜访内网畅捷通 1、咱们要当初官网下载闪库客户端,地址：www.ipyingshe.com 2、下载后咱们解压，而后双击运行客户端，软件是免装置的； 3、下载后咱们运行客户端，注册账号 4、注册后登录，咱们开明收费隧道，收费通道带宽2mbps，不限度流量 5、开明收费隧道时候，配置隧道信息，以畅捷通为例；本地怎么拜访畅捷通，就怎么配置隧道 隧道根本信息：能够自定义 内网ip：127.0.0.1(就是本机ip) 内网端口：80（畅捷通端口）每个人的端口可能不一样，依据本人状况而定 配置结束点击立刻开明 6、这时候咱们启动隧道，会看到软件调配给咱们一个映射外网地址，http模式咱们间接拜访域名就能够，tcp模式咱们须要域名加上长的外网端口拜访，这里畅捷通，咱们http拜访就能够 7、咱们复制外网地址在浏览器拜访试一下，能够看到胜利拜访到内网的畅捷通； 综上所述，就是应用闪库实现外网拜访内网畅捷通的教程；当然，像ERP、用友、金蝶、管家婆等都是能够应用的，稳定性棒棒的！

问题咱们有一个 SQL，用于找到没有主键 / 惟一键的表，然而在 MySQL 5.7 上运行特地慢，怎么办？ 试验咱们搭建一个 MySQL 5.7 的环境，此处省略搭建步骤。 写个简略的脚本，制作一批带主键和不带主键的表： 执行一下脚本： 当初执行以下 SQL 看看成果： ... 执行了 16.80s，感觉是十分慢了。 当初用一下 DBA 三板斧，看看执行打算： 感觉有点惨，因为 information_schema.columns 是元数据表，没有必要的统计信息。 那咱们来 show warnings 看看 MySQL 改写后的 SQL： 咱们格式化一下 SQL： 能够看到 MySQL 将 select from A where A.x not in (select x from B) //非关联子查问转换成了 select from A where not exists (select 1 from B where B.x = a.x) //关联子查问如果咱们本人是 MySQL，在执行非关联子查问时，能够应用很简略的策略： ...

咱们应用容器的形式部署数据库组件，特地是企业有大量的我的项目开发业务的，部署的开发、测试数据库组件较多时。常常会遇到以下问题： 业务须要应用数据库，但部署完数据库后，须要在数据库中执行创立schema的操作或者一些初始化数据的创立。开发测试多套部署环境，须要多次重复1的步骤。我的项目比拟多，工夫久了我的项目须要的数据库Schema不分明。我的项目交付时数据库Schema管理混乱。当初如果是应用Go等语言研发的业务零碎，都具备了ORM层主动初始化和更新Schema的能力，如果是这样本文对你无用。但目前大多数其余开发语言的业务都不具备这种能力。 如果咱们把数据库也作为一个业务中的一个服务模块来治理的话，咱们心愿服务启动后即可间接实现Schema的初始化，间接提供数据服务能力。 那么在Rainbond中如何达成这样的成果呢？ Schema初始化在传统模式中个别有两种计划： 在数据库启动后手动导入；人工通过客户端操作，没有自动化水平可言；在业务服务启动时连贯数据库进行初始化，依赖业务服务端的能力。能够看出，这两种形式都存在各自的弊病，那么有没有形式可能让数据库启动时主动初始化指定的数据呢？答案是 有！ 咱们以MySQL为例， 官网对于 Docker 有着良好的反对，首先来看 Dockerhub上 Mysql官网镜像 的一段形容: 在数据库容器首次启动时，将创立一个指定名称的新数据库，并应用提供的环境变量对其进行初始化。 此外，它将执行在 /docker-entrypoint-initdb.d 中找到的扩大名为 .sh，.sql 和 .sql.gz 的文件。 文件将按字母程序执行。 默认状况下，SQL文件将导入到MYSQL_DATABASE 变量指定的数据库中。因而咱们只须要在Mysql镜像工作机制的根底上保护好数据库初始化所须要的SQL即可。上文咱们说到把数据库也作为一个独立的服务模块，咱们也能够通过代码把Sql等脚步治理起来，划分版本分支。 Rainbond 反对多种组件创立形式，在这里咱们采纳 从源码创立组件 的形式，编写 Dockerfile 并上传至反对 Git/Svn 协定的客户端，即可在平台间接进行构建；这种形式 通明、可复用、并且可能进行自动化构建。 目录构造 ./└── Dockerfile └── config ├── my.cnf ├── conf.d ├── docker.cnf └── sql ├── init_database └── README.md 根底镜像FROM mysql:latestMAINTAINER Aaron <Aaron_ops@163.com> 把sql文件拷贝到/docker-entrypoint-initdb.d/目录下，以便启动时主动执行这个sqlCOPY ./sql/*.sql /docker-entrypoint-initdb.d 拷贝mysql配置文件COPY ./config/ /etc/mysql/ Mysql明码ENV MYSQL_ROOT_PASSWORD rainbond 数据长久化目录VOLUME [ "/var/lib/mysql" ] ...

1、索引是什么1.1索引简介索引是表的目录，是数据库中专门用于帮忙用户疾速查问数据的一种数据结构。相似于字典中的目录，查找字典内容时能够依据目录查找到数据的寄存地位，以及疾速定位查问数据。对于索引，会保留在额定的文件中。 1.2次要留神的中央：(1).索引能够进步查问速度，会减慢写入速度，索引的毛病时创立和保护索引须要消耗工夫。 (2).索引并不是越多越好，索引诚然能够进步相应的select的效率，但同时也升高了insert及update的效率，因为insert或update是有可能会重建索引。 1.3什么样的字段适宜创立索引(1).表的主键、外键必须有索引；外键是惟一的，而且常常会用来查问。 (2).常常与其余表进行连贯的表，在连贯字段上应该建设索引。 (3).数据量超过300的表应该有索引。 (4).重要的SQL或调用频率高的SQL，比方经常出现在where子句中的字段，order by,group by, distinct的字段都要增加索引。 (5).常常用到排序的列上，因为索引曾经排序。 (6).常常用在范畴内搜寻的列上创立索引，因为索引曾经排序了，其指定的范畴是间断的。 1.4什么场景不适宜创立索引1.对于那些在查问中很少应用或者参考的列不应该创立索引，这是因为，既然这些列很少应用到，因而有索引或者无索引，并不能进步查问速度。相同，因为减少了索引，反而升高了零碎的保护速度和增大了空间需要。 2.对于那 些只有很少数据值的列也不应该减少索引。因为原本后果汇合就是相当于全表查问了，所以没有必要。这是因为，因为这些列的取值很少，例如人事表的性别列，在查问的后果中，后果集的数据行占了表中数据行的很大比 例，即须要在表中搜寻的数据行的比例很大。减少索引，并不能显著放慢检索速度。 3.对于那些定义为text, image和bit数据类型的列不应该减少索引。这是因为，这些列的数据量要么相当大，要么取值很少。 4、当批改性能远远大于检索性能时，不应该创立索引。这是因为，批改性能和检索性能是互相矛盾的。当减少索引时，会进步检索性能，然而会升高批改性能。当缩小索引时，会进步批改性能，升高检索性能。因 此，当批改性能远远大于检索性能时，不应该创立索引。 5.不会呈现在where条件中的字段不该建设索引。 6.如果列均匀分布在 1 和 100 之间，却只是查问中where key_part1 > 1 and key_part1 < 90不应该减少索引 1.5索引应用以及设计规范1、越小的数据类型通常更好：越小的数据类型通常在磁盘、内存和CPU缓存中都须要更少的空间，解决起来更快。简略的数据类型更好：整型数据比起字符，解决开销更小，因为字符串的比拟更简单 2、尽量避免null：应该指定列为not null， 含有空值的列很难进行查问优化，因为它们使得索引、索引的统计信息以及比拟运算更加简单，也可能导致复合索引有效 3、主键抉择策略 1) 每个表必须显示指定主键； 2) 主键尽量为一个字段，且为数字类型,防止应用字符串； 3) 主键尽量放弃增长趋势，倡议应用id的生成器； 4)主键尽量杜绝联结索引 4、每个表的索引个数尽量少于5个，防止创立反复冗余索引；每个组合索引尽量避免超过3个字段，索引不是越多越好，审慎增加索引，综合思考数据分布和数据更新 5、重要的SQL或调用频率高的SQL 1) update/select/delete的where条件列字段都要增加索引； 2) order by , group by, distinct的字段都要增加索引 6、避免出现index merge（单索引or的查问）；正当利用covering index 7、组合索引创立时，把区分度(选择性)高的字段放在后面；依据SQL的个性，调整组合索引的程序 8、对于varchar字段加索引，倡议应用前缀索引，从而减小索引大小 2、索引的创立和删除2.1创立数据表时创立索引的根本语法结构：create table 表名( 字段名1 数据类型 [约束条件...] ...

什么是事务事务是应用程序中一系列紧密的操作，所有操作必须胜利实现，否则在每个操作中所作的所有更改都会被吊销。也就是事务具备原子性，一个事务中的一系列的操作要么全副胜利，要么一个都不做。 事务的完结有两种，当事务中的所以步骤全副胜利执行时，事务提交。如果其中一个步骤失败，将产生回滚操作，吊销吊销之前到事务开始时的所以操作。 事务的 ACID事务具备四个特色：原子性（ Atomicity ）、一致性（ Consistency ）、隔离性（ Isolation ）和持续性（ Durability ）。这四个个性简称为 ACID 个性。 原子性。事务是数据库的逻辑工作单位，事务中蕴含的各操作要么都做，要么都不做一致性。事 务执行的后果必须是使数据库从一个一致性状态变到另一个一致性状态。因而当数据库只蕴含胜利事务提交的后果时，就说数据库处于一致性状态。如果数据库系统 运行中产生故障，有些事务尚未实现就被迫中断，这些未实现事务对数据库所做的批改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是 不统一的状态。隔离性。一个事务的执行不能其它事务烦扰。即一个事务外部的操作及应用的数据对其它并发事务是隔离的，并发执行的各个事务之间不能相互烦扰。持续性。也称永久性，指一个事务一旦提交，它对数据库中的数据的扭转就应该是永久性的。接下来的其它操作或故障不应该对其执行后果有任何影响。Mysql的四种隔离级别SQL规范定义了4类隔离级别，包含了一些具体规定，用来限定事务内外的哪些扭转是可见的，哪些是不可见的。低级别的隔离级个别反对更高的并发解决，并领有更低的零碎开销。 Read Uncommitted（读取未提交内容）在该隔离级别，所有事务都能够看到其余未提交事务的执行后果。本隔离级别很少用于理论利用，因为它的性能也不比其余级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。 Read Committed（读取提交内容）这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简略定义：一个事务只能看见曾经提交事务所做的扭转。这种隔离级别 也反对所谓的不可反复读（Nonrepeatable Read），因为同一事务的其余实例在该实例解决其间可能会有新的commit，所以同一select可能返回不同后果。 Repeatable Read（可重读）这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过实践上，这会导致另一个辣手的问题：幻读 （Phantom Read）。简略的说，幻读指当用户读取某一范畴的数据行时，另一个事务又在该范畴内插入了新行，当用户再读取该范畴的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发管制（MVCC，Multiversion Concurrency Control）机制解决了该问题。 Serializable（可串行化）这是最高的隔离级别，它通过强制事务排序，使之不可能互相抵触，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时景象和锁竞争。 这四种隔离级别采取不同的锁类型来实现，若读取的是同一个数据的话，就容易产生问题。例如： 脏读(Drity Read)：某个事务已更新一份数据，另一个事务在此时读取了同一份数据，因为某些起因，前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。不可反复读(Non-repeatable read):在一个事务的两次查问之中数据不统一，这可能是两次查问过程两头插入了一个事务更新的原有的数据。幻读(Phantom Read):在一个事务的两次查问中数据笔数不统一，例如有一个事务查问了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查问中，就有几列数据是未查问进去的，如果此时插入和另外一个事务插入的数据，就会报错。在MySQL中，实现了这四种隔离级别，别离有可能产生问题如下所示： 测试Mysql的隔离级别上面，将利用MySQL的客户端程序，咱们别离来测试一下这几种隔离级别。 测试数据库为demo，表为test；表构造： 两个命令行客户端别离为A，B；一直扭转A的隔离级别，在B端批改数据。 将A的隔离级别设置为read uncommitted(未提交读) A：启动事务，此时数据为初始状态 B：启动事务，更新数据，但不提交 A：再次读取数据，发现数据曾经被批改了，这就是所谓的“脏读” B：回滚事务 A：再次读数据，发现数据变回初始状态 通过下面的试验能够得出结论，事务B更新了一条记录，然而没有提交，此时事务A能够查问出未提交记录。造成脏读景象。未提交读是最低的隔离级别。 将客户端A的事务隔离级别设置为read committed(已提交读) A：启动事务，此时数据为初始状态 B：启动事务，更新数据，但不提交 A：再次读数据，发现数据未被批改 B：提交事务 ...

比方创立两个简略的表，如下。 CREATE table clazz( id INT AUTO_INCREMENT,~~~~ name varchar(20) NOT NULL, total INT UNSIGNED NOT NULL, PRIMARY KEY(id) )ENGINE=InnoDB DEFAULT CHARSET=utf8;CREATE table student( id INT AUTO_INCREMENT, name varchar(20) not null, age INT NOT NULL, clazz_id INT, PRIMARY KEY(id), FOREIGN KEY(clazz_id) references clazz(id))ENGINE=InnoDB DEFAULT CHARSET=utf8;student表就会无奈创立，会显示 起因是被援用的外键，必须是非空的，不然是无奈援用的。 把 clazz 表的 id 改为 not null ，即可。如下 CREATE table clazz( id INT NOT NULL AUTO_INCREMENT, name varchar(20) NOT NULL, total INT UNSIGNED NOT NULL, PRIMARY KEY(id) )ENGINE=InnoDB DEFAULT CHARSET=utf8; ...

前言： MySQL 主从架构应该是最罕用的一组架构了。从库会实时同步主库传输来的数据，个别从库能够作为备用节点或作查问应用。其实不只是主库须要多关注，从库有时候也要常常保护，本篇文章将会分享几点从库保护教训，一起来学习吧。 1.主从复制倡议采纳 GTID 模式GTID 即全局事务 ID（Global Transaction ID），GTID 实际上是由 server_uuid:transaction_id 组成的。其中 server_uuid 是一个 MySQL 实例的惟一标识， transaction_id 代表了该实例上曾经提交的事务数量，并且随着事务提交枯燥递增，所以 GTID 可能保障每个 MySQL 实例事务的执行（不会反复执行同一个事务，并且会补全没有执行的事务）。 基于 GTID 的主从复制能够取代过来通过 binlog 文件偏移量定位复制地位的传统形式。特地是对于一主多从的架构，借助GTID，在产生主备切换的状况下，MySQL 的其它 Slave 能够主动在新主上找到正确的复制地位，这大大简化了简单复制拓扑下集群的保护，也缩小了人为设置复制地位产生误操作的危险。另外，基于 GTID 的复制能够疏忽曾经执行过的事务,缩小了数据产生不统一的危险。 2.倡议从库参数尽量和主库保持一致为保障主从库数据一致性，倡议从库版本与主库统一，相干参数尽量和主库保持一致。比方字符集、默认存储引擎、sql_mode 这类参数要设置一样。特地是一些不可动静批改的参数，倡议提前写入配置文件并和主库统一。 3.备份可在从库端进行MySQL 全量备份会对服务器造成肯定压力，有时也会短暂持有全局锁。特地是数据量大，业务忙碌的数据库，全量备份可能会对业务产生影响。倡议将备份脚本部署在从库服务器上，全量备份能够放在从库端进行，这样能缩小备份过程中对于主库业务的影响。 4.从库倡议设为只读对于数据库读写状态，次要靠 read_only 全局参数来设定，默认状况下，数据库是用于读写操作的，所以 read_only 参数是 0 或 false 状态。这时候不论是本地用户还是近程拜访数据库的用户，只有有权限都能够进行读写操作。 为防止从库产生手动更新操作，倡议将从库设置为只读，行将 read_only 参数设置为1。 read_only=1 只读模式，不会影响从库同步复制的性能，从库依然会读取 master 上的日志，并且在 slave 端利用日志，保障主从数据库同步统一。从库设为只读会限度不具备 super 权限的用户进行数据批改操作，一般的利用用户进行 insert 、 update 、 delete 等会产生数据变动的 DML 操作时，都会报出数据库处于只读模式。这样能无效避免从库产生更新操作。 此外，有条件的状况下，从库能够承当局部查问工作。比方一些报表聚合剖析查问或者内部服务查问都能够配置从库查问，缩小对主库的压力。 ...

首先咱们先来理解一下每个浮点类型的存储大小和范畴，如下表： 类型大小范畴（有符号）范畴（无符号）用处==float==4 bytes(-3.402 823 466 E+38，-1.175 494 351 E-38)，0，(1.175 494 351 E-38，3.402 823 466 351 E+38)0，(1.175 494 351 E-38，3.402 823 466 E+38)单精度 浮点数值==double==8 bytes(-1.797 693 134 862 315 7 E+308，-2.225073858507 2014E-308)，0，(2.225 073 858 507 201 4 E-308，1.797 693 134 862 315 7 E+308)0，(2.225 073 858 507 201 4 E-308，1.797 693 134 862 315 7 E+308)双精度 浮点数值decimal对decimal(M,D) ，如果M>D，为M+2否则为D+2依赖于M和D的值依赖于M和D的值小数值那么MySQL中这三种都是浮点类型 它们彼此的区别又是什么呢 ？？ float 浮点类型用于示意单精度浮点数值double浮点类型用于示意双精度浮点数值这里必定有些小伙伴要问了 什么是单精度？ 什么是双精度 ？上面咱们就来简略理解一下吧! 首先，咱们晓得一个bytes(字节) 占8位 对吧! ...

你可能曾经晓得int(1)这个长度1并不代表容许存储的宽度!但对这个长度很多人也没有真正钻研过到底代表什么,明天我就来简略的剖析一下!先看一个简略的建表小案例：create table test( id int(11) unsigned NOT NULL AUTO_INCREMENT, uid int(3) NOT NULL, PRIMARY KEY (id)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这里以uid字段为例，咱们这里设置的是int(3) 那么问题来了 难道咱们设置int(3)，就不能存放数据1234了？那么你齐全能够测试一下 输出如下SQL语句：`insert into test (uid) VALUES(1234);insert into test (uid) VALUES(12345678);`后果图如下： 小伙伴们通过下面的SQL语句能够发现 胜利把数据1234插入, 并且咱们还能够插入寄存更多位的数据! 这是为什么呢? 看上面：起因如下这个int(n)咱们能够简略的了解为：这个长度是为了通知MySQL数据库，咱们这个字段的存储的数据的宽度为n位数, 当然如果你不是存储的n位数, 然而(只有在该类型的存储范畴之内）MySQL也能失常存储!那么咱们能够从新来建设test2表, 而后这一次咱们把uid字段加上: unsigned 和 zerofill 这两个字段束缚。字段束缚会在前面具体讲到。MySQL代码如下:`create table test2( id int(11) unsigned NOT NULL AUTO_INCREMENT, uid int(3) unsigned zerofill NOT NULL, PRIMARY KEY (id)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;`当初我的uid字段：长度(n)=3, 字段束缚=unsigned 和 zerofill，备: (无符号束缚 和 用0来填充位数束缚）。设置这个束缚的字段后,再往表里插入数据，零碎会主动把uid字段不够3位的在左侧用0来填充。小伙伴齐全能够测试一下代码: 向uid字段插入一个33的数字，代码如下：`insert into test2 (uid) VALUES(33);`后果如下图:大家是不是惊奇的发现有余长度3的时候， 真的用0来 从右边开始填充! 哈哈哈所以，当初咱们应该分明的晓得,int后的长度n 与你寄存的数值型的数的大小无关!小结在定义表字段数据类型为int类型的时候,前面的长度n所代表的长度是没有任何意义的, 只有在该类型的存储范畴之内MySQL也能失常存储! 如果肯定要左侧补0 那么这个字段必须要有zerofill束缚和unsigned 无符号束缚! ...

一、引言来此教程简要领导针对Mysql数据库的基于GTID的双主备份。 二、步骤来0.环境筹备两台Centos零碎的服务器,服务器调配在同一网段，并保障互相网络畅通-server-a ip : 192.168.1.220 -server-b ip : 192.168.1.221 服务器事后装置好Docker，Docker-Compose，pull Mysql:8.0镜像Navicat for mysql 执行数据库命令1.设置Mysql配置文件新建mysql配置文件my.cnf，具体配置省去，只阐明主从备份相干配置。 1.1设置server-a的配置文件与主主备份相干的配置 [mysqld]#为服务器调配id，能够自定义，不辨别大小，起标识作用。不同数据库节点调配不同的idserver_id=1# 关上Mysql 日志，日志格局为二进制log-bin=mysql-bin# 可选项Mixed,Statement,Row，默认格局是 Statement，mixed混合Satement，ROW两种模式binlog_format=mixed#当启用时，服务器通过只容许执行能够应用GTID平安地记录的语句来强制GTID一致性。enforce-gtid-consistency=true#启用基于GTID的复制，启用之前必须保障enforce-gtid-consistency=truegtid_mode=ON#该选项让从库写入哪些来自于主库的更新，并把这些更新写入bin-log文件，一台服务器即做主库又做从库必须开启log-slave-updates=true一些定制化的配置 针对主服务器 疏忽不同步主从的数据库 #个别设置 sys,performace_schema,infomation_schema,mysqlbinlog-ignore-db=<YOUR-DB-NAME>容许同步的数据库 #个别设置成备份的生产数据的数据库binlog-do-db=<YOUR-DB-NAME>针对从服务器 疏忽不同步主从的数据库 #个别设置 sys,performace_schema,infomation_schema,mysqlreplicate-ignore-db=<YOUR-DB-NAME>容许同步的数据 #个别设置成备份的生产数据的数据库replicate-do-db=<YOUR-DB-NAME>因为咱们配置的是双主服务器，每台服务器既要作为主又要作为从。所以以上针对主，从服务器的个性化配置在两台数据库都要按具体业务需要进行配置。 另，以上4个定制化参数可反复设置，如下图 replicate-ignore-db=sysreplicate-ignore-db=mysql1.2 设置server-b配置区别于server-a的配置，改变以下配置即可,其余定制化配置按需自定义 #server_id 必须举世无双server_id=22.编辑docker-compose.yml两个服务器配置雷同内容的docker-compoe.yml文件 version: '3.7'services: #mysql service mysql: image: mysql:8.0 ports: - "3306:3306" command: --default-authentication-plugin=mysql_native_password --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci --default-time-zone='+8:00' restart: always volumes: #长久化数据库，留神门路 - ./data/db:/var/lib/mysql #替换数据库配置文件，留神门路 - ./my.conf:/etc/mysql/conf.d/mysql.cnf environment: MYSQL_ROOT_PASSWORD: <YOUR_PAASWORD> container_name: mysql_service3.docker 开启数据库容器每个服务器针对数据库的docker-compose目录如下（供参考）： -mysql_replicate docker-compose.yml ...

写在后面明天，一位哥们打电话来问我说误操作了他们公司数据库中的数据，如何复原。他本来的想法是登录数据库update一个记录，后果忘了加where条件，于是喜剧产生了。明天，咱们不讲如何复原误操作的数据（前面专门讲如何复原误删除的数据），咱们讲讲如何从源头上防止这样的问题，这才是防止相似问题的根本措施。 如果文章对你有所帮忙，请不要吝惜你的点赞、在看、留言和转发，你的反对是我继续创作的最大能源！ 在mysql命令加上选项-U后，当收回没有WHERE或LIMIT关键字的UPDATE或DELETE时，MySQL程序就会拒绝执行。那么，咱们基于MySQL提供的这项设置，就能够轻松实现如何最大水平避免人为误操作MySQL数据库了。什么？你不信？不信咱们就从MySQL的帮忙阐明说起，一起来看看如何基于MySQL的-u选项实现如何最大水平避免人为误操作MySQL数据库。 MySQL帮忙阐明[root@binghe~]# mysql --help|grep dummy -U, --i-am-a-dummy Synonym for option --safe-updates, -U.i-am-a-dummy FALSE在mysql命令加上选项-U后，当收回没有WHERE或LIMIT关键字的UPDATE或DELETE时，MySQL程序就会拒绝执行。 指定-U登录测试[root@binghe~]# mysql -uroot -proot -S /data/3306/mysql.sock -UWelcome to the MySQL monitor. Commands end with ; or \g.Your MySQL connection id is 14Server version: 5.7.24-log MySQL Community Server (GPL)Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.Oracle is a registered trademark of Oracle Corporation and/or itsaffiliates. Other names may be trademarks of their respectiveowners.Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.mysql> delete from oldboy.student;ERROR 1175 (HY000): You are using safe update mode and you tried to update a table without a WHERE that uses a KEY columnmysql> quitBye提醒：不加条件无奈删除，目标达到。 ...

咱们晓得在Mysql 中存储小数有三种数据类型可做抉择，到底该抉择哪一种数据格式，其实并没有对立的答案，得依据理论场景去剖析，哪一种更适合。 场景重现先来看这样一个例子，假如目前有一张表用来存储用户的积分 CREATE TABLE `table1` ( `integral` float(10,2) DEFAULT NULL) ENGINE=InnoDB DEFAULT CHARSET=utf8;而后向这张表中插入一条数据： mysql> INSERT INTO `table1` (`integral`) VALUES (131072.32);Query OK, 1 row affected (0.00 sec)mysql> SELECT * FROM `table1`;+-----------+| integral |+-----------+| 131072.31 |+-----------+1 row in set (0.00 sec)通过查问数据表能够看到该条记录并不是131072.32 而是131072.31，为什么会这样？这个问题间接暴露出了其余什么问题？ 失落数据是否是失常景象？为什么会少0.01，有没有可能少0.02，或者少1，少10甚至少100？怎么样能力让咱们的数据尽量精确？精度是如何失落的数值类型存储需要： 列类型存储需要分配内存空间FLOAT(p)如果0 <= p <= 24为4个字节, 如果25 <= p <= 53为8个字节32,64FLOAT4个字节32DOUBLE [PRECISION], item REAL8个字节64DECIMAL(M,D), NUMERIC(M,D)变长 通过查阅官网文档，能够看到在计算机的世界中，浮点数进行存储时，必须要先转换为二进制，艰深一点讲也就是浮点数的精度实际上是由二进制的精度来决定的。 咱们晓得对于float类型的数据，只调配了32位的存储空间，对于double类型值调配了64位，然而并不是所有的实数都能转成32位或者64位的二进制模式，如果超过了，就会呈现截断，这就是误差的起源。 比方将下面例子中的 131072.32 转成二进制后的数据为： 100000000000000000.0101000111101011100001010001111010111000010100011111…这是一个无穷数，对于float 类型，只能截取前32位进行存储，对于double只能截取前64位进行存储。 对于 float 而言，最终存储的值是：01001000000000000000000000010100对于 double 而言，最终存储的值是：0100000100000000000000000000001010001111010111000010100011110101所以咱们临时能够得出一个论断： ...

作者：Arunjith Aravindan翻译：管长龙本文起源：https://www.percona.com/blog/...MySQL 8 之前，应用的动静变量不是永久性的，并且在重启后会重置。可在运行时应用 SET 语句更改这些变量，以影响以后实例的操作，然而咱们必须手动更新 my.cnf 配置文件以使其长久化。在许多状况下，从服务端更新 my.cnf 并不是一个不便的抉择，并且使变量仅被更新能力在后续重新启动时动静还原，而没有任何历史记录。长久化零碎变量是 MySQL 8 中引入的性能之一。新性能可帮忙 DBA 动静更新变量并注册它们，而无需从服务器端拜访配置文件。 如何长久化全局零碎变量？与 SET GLOBAL 一样，SET PERSIST 是可用于在运行时更新零碎变量并使它们在重新启动后放弃不变的命令。当咱们应用 PERSIST 关键字时，变量更改将更新到数据目录中的 mysqld-auto.cnf 选项文件。mysqld-auto.cnf 是仅在第一次执行 PERSIST 或 PERSIST_ONLY 语句时创立的 JSON 格式文件。让咱们以更新最大连接数为例，看看此性能的工作原理。 mysql> SET PERSIST max_connections = 1000;Query OK, 0 rows affected (0.00 sec)mysql> select @@max_connections\G*************************** 1. row ***************************@@max_connections: 10001 row in set (0.00 sec)生成的 mysqld-auto.cnf 如下所示： cat /var/lib/mysql/mysqld-auto.cnf{ "Version" : 1 , "mysql_server" : { "max_connections" : { "Value" : "1000" , "Metadata" : { "Timestamp" : 1602543199335909 , "User" : "root" , "Host" : "localhost" } } } }如何保留只读的零碎变量？当须要更改只读变量时，咱们须要应用 PERSIST_ONLY 关键字。该子句更新 mysqld-auto.cnf 文件中的更改，但不适用于 MySQL，在下一次 MySQL 重新启动时持续存在。这使得 PERSIST_ONLY 适宜配置只能在服务器启动时设置的只读零碎变量。 ...

MySQL 事务次要用于解决操作量大，复杂度高的数据。比方开单，须要增加给订单表减少记录，还须要减少订单的各种相干明细，操作复杂度高，这些操作语句须要形成一个事务。在 MySQL 命令行的默认设置下，事务都是主动提交的，即执行 SQL 语句后就会马上执行 COMMIT 操作。因而要显式地开启一个事务务须应用命令 BEGIN 或 START TRANSACTION，或者执行命令 SET AUTOCOMMIT=0，用来禁止应用以后会话的主动提交。 1、事务及其四大个性在 MySQL 中只有应用了 Innodb 数据库引擎的数据库或表才反对事务事务处理能够用来保护数据库的完整性，保障成批的 SQL 语句要么全副执行，要么全副不执行。一般来说，事务须要满足4个条件（ACID）：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）mysql默认是主动提交事务的1.1原子性一个事务（transaction）中的所有操作，要么全副实现，要么全副不实现，不会完结在两头某个环节。事务在执行过程中产生谬误，会被回滚（Rollback）到事务开始前的状态，就像这个事务素来没有执行过一样。 1.2一致性在事务开始之前和事务完结当前，数据库的完整性没有被毁坏。这示意写入的材料必须完全符合所有的预设规定，这蕴含材料的精确度、串联性以及后续数据库能够自发性地实现预约的工作。 1.3隔离性数据库容许多个并发事务同时对其数据进行读写和批改的能力，隔离性能够避免多个事务并发执行时因为穿插执行而导致数据的不统一。事务隔离分为不同级别，包含读未提交（Read uncommitted）、读提交（read committed）、可反复读（repeatable read）和串行化（Serializable）。 1.4持久性事务处理完结后，对数据的批改就是永恒的，即使系统故障也不会失落。 2、事务的隔离级别隔离级别 脏读（Dirty Read） 不可反复读（NonRepeatable Read） 幻读（Phantom Read） 未提交读（Read uncommitted） 可能 可能 可能 已提交读（Read committed） 不可能 可能 可能 可反复读（Repeatable read） 不可能 不可能 可能 可串行化（Serializable ） 不可能 不可能 不可能 InnoDB默认是可反复读级别的 脏读: 脏读就是指当一个事务正在拜访数据，并且对数据进行了批改，而这种批改还没有提交到数据库中，这时，另外一个事务也拜访这个数据，而后应用了这个数据。不可反复读:是指在一个事务内，屡次读同一数据。在这个事务还没有完结时，另外一个事务也拜访该同一数据。那么，在第一个事务中的两次读数据之间，因为第二个事务的批改，那么第一个事务两次读到的的数据可能是不一样的。这样就产生了在一个事务内两次读到的数据是不一样的，因而称为是不可反复读。幻读:第一个事务对一个表中的数据进行了批改，这种批改波及到表中的全副数据行。同时，第二个事务也批改这个表中的数据，这种批改是向表中插入一行新数据。那么，当前就会产生操作第一个事务的用户发现表中还有没有批改的数据行，就好象产生了幻觉一样，幻读是数据行记录变多了或者少了。区别：脏读是指读取了未修改完的记录，不可反复读指因为被其它事务批改了记录导致某事务两次读取记录不统一，而幻读是指因为其它事务对表做了增删导致某事务两次读取的表记录数不统一问题。 2.1、第1级别未提交读(Read Uncommitted)容许脏读，也就是可能读取到其余会话中未提交事务批改的数据 2.2、第2级别提交读(Read Committed)只能读取到曾经提交的数据。Oracle等少数数据库默认都是该级别 (不反复读) 2.3、第3级别可反复读(Repeated Read)可反复读。在同一个事务内的查问都是事务开始时刻统一的，InnoDB默认级别。在SQL规范中，该隔离级别打消了不可反复读，然而还存在幻象读 2.4、第4级别串行读(Serializable)齐全串行化的读，每次读都须要取得表级共享锁，读写互相都会阻塞 3、mysql事务相干命令3.1查看mysql零碎的事务隔离级别mysql> SELECT @@global.tx_isolation; ...

首先设置 maven 下载仓库为 aliyun拜访https://maven.aliyun.com/mvn/...而后在dbeaver -> 窗口 -> 连贯 -> 驱动 -> maven,增加方才复制的阿里云链接而后挪动到第一位而后点击 apply and close 接着点开驱动管理器轻易选一个mysql点击复制，批改驱动名称，比方mysql8,而后下载更新，抉择版本最初点击下载就能够了 参考链接：DBeaver 设置 maven 下载仓库为 aliyunDBeaver驱动装置

25、查问出计算机系老师所教课程的成绩表子查问 SELECT tno FROM teacher WHERE depart='计算机系';SELECT cno FROM course WHERE tno IN(SELECT tno FROM teacher WHERE depart='计算机系');SELECT * FROM score WHERE cno IN(SELECT cno FROM course WHERE tno IN(SELECT tno FROM teacher WHERE depart='计算机系'));sno cno degree103 3-245 86105 3-245 75109 3-245 68101 3-105 90102 3-105 91103 3-105 92104 3-105 88105 3-105 88109 3-105 7626、查问计算机系与电子工程系不同职称的老师的tname和profunion求并集，联结在一起 SELECT tname,prof FROM teacher WHERE depart='计算机系' AND prof NOT IN(SELECT prof FROM teacher WHERE depart='电子工程系')UNIONSELECT tname,prof FROM teacher WHERE depart='电子工程系' AND prof NOT IN(SELECT prof FROM teacher WHERE depart='计算机系');27、查问选修编号为3-105课程且问题至多高于选修编号为3-245的同学的cno，sno和degree，并按degree从高到底排序至多的含意：大于其中至多一个，any ...

MySQL表中的连贯形式其实非常简单，这里就简略的列举出他们的特点。表的连贯（JOIN）能够分为内连贯（JOIN/INNER JOIN）和外连贯（LEFT JOIN/RIGHT JOIN）。 首先咱们看一下咱们本次演示的两个表： mysql> SELECT * FROM student;+------+----------+------+------+| s_id | s_name | age | c_id |+------+----------+------+------+| 1 | xiaoming | 13 | 1 || 2 | xiaohong | 41 | 4 || 3 | xiaoxia | 22 | 3 || 4 | xiaogang | 32 | 1 || 5 | xiaoli | 41 | 2 || 6 | wangwu | 13 | 2 || 7 | lisi | 22 | 3 || 8 | zhangsan | 11 | 9 |+------+----------+------+------+8 rows in set (0.00 sec)mysql> SELECT * FROM class;+------+---------+-------+| c_id | c_name | count |+------+---------+-------+| 1 | MATH | 65 || 2 | CHINESE | 70 || 3 | ENGLISH | 50 || 4 | HISTORY | 30 || 5 | BIOLOGY | 40 |+------+---------+-------+5 rows in set (0.00 sec)首先，表要能连贯的前提就是两个表中有雷同的能够比拟的列。 ...

MYSQL应该是最风行的WEB后端数据库。大量利用于PHP，Ruby，Python，Java 等Web语言开发我的项目中，无论NOSQL倒退如许快，都不影响大部分架构师抉择MYSQL作为数据存储。 MYSQL如此不便和稳固，以至于咱们在开发 WEB 程序的时候非常少想到它。即便想到优化也是程序级别的，比如不要写过于耗费资源的SQL语句。可是除此之外，在整个零碎上依然有十分多可能优化的中央。 1 优化原理说起MySQL的查问优化，置信大家会想到：不能应用SELECT *、不应用NULL字段、正当创立索引、为字段抉择适合的数据类型..... 你是否真的了解这些优化技巧？是否了解其背地的工作原理？在理论场景下性能真有晋升吗？我想未必。因此了解这些优化倡议背地的原理就尤为重要，心愿本文能让你从新扫视这些优化倡议，并在理论业务场景下正当的使用。 MySQL逻辑架构如果能在头脑中构建一幅MySQL各组件之间如何协同工作的架构图，有助于深刻了解MySQL服务器。下图展现了MySQL的逻辑架构图。 MySQL逻辑架构 MySQL逻辑架构整体分为三层，最上层为客户端层，并非MySQL所独有，诸如：连贯解决、受权认证、平安等性能均在这一层解决。 MySQL大多数外围服务均在两头这一层，包含查问解析、剖析、优化、缓存、内置函数(比方：工夫、数学、加密等函数)。所有的跨存储引擎的性能也在这一层实现：存储过程、触发器、视图等。 最上层为存储引擎，其负责MySQL中的数据存储和提取。和Linux下的文件系统相似，每种存储引擎都有其劣势和劣势。两头的服务层通过API与存储引擎通信，这些API接口屏蔽了不同存储引擎间的差别。 MySQL查问过程　咱们总是心愿MySQL可能取得更高的查问性能，最好的方法是弄清楚MySQL是如何优化和执行查问的。一旦了解了这一点，就会发现：很多的查问优化工作实际上就是遵循一些准则让MySQL的优化器可能依照料想的正当形式运行而已。 当向MySQL发送一个申请的时候，MySQL到底做了些什么呢？ MySQL查问过程 - 客户端/服务端通信协议MySQL客户端/服务端通信协议是“半双工”的：在任一时刻，要么是服务器向客户端发送数据，要么是客户端向服务器发送数据，这两个动作不能同时产生。一旦一端开始发送音讯，另一端要接管残缺个音讯能力响应它，所以咱们无奈也毋庸将一个音讯切成小块独立发送，也没有方法进行流量管制。 客户端用一个独自的数据包将查问申请发送给服务器，所以当查问语句很长的时候，须要设置max_allowed_packet参数。然而须要留神的是，如果查问切实是太大，服务端会回绝接管更多数据并抛出异样。 与之相同的是，服务器响应给用户的数据通常会很多，由多个数据包组成。然而当服务器响应客户端申请时，客户端必须残缺的接管整个返回后果，而不能简略的只取后面几条后果，而后让服务器进行发送。因此在理论开发中，尽量放弃查问简略且只返回必须的数据，减小通信间数据包的大小和数量是一个十分好的习惯，这也是查问中尽量避免应用SELECT *以及加上LIMIT限度的起因之一。 - Linuxc/c++服务器开发高阶视频学习材料+qun720209036获取内容包含C/C++，Linux，Nginx，ZeroMQ，MySQL，Redis，MongoDB，ZK，流媒体，P2P，K8S，Docker，TCP/IP，，Linux内核，协程，DPDK多个高级知识点。 - 查问缓存　在解析一个查问语句前，如果查问缓存是关上的，那么MySQL会查看这个查问语句是否命中查问缓存中的数据。如果以后查问恰好命中查问缓存，在查看一次用户权限后间接返回缓存中的后果。这种状况下，查问不会被解析，也不会生成执行打算，更不会执行。 MySQL将缓存寄存在一个援用表（不要了解成table，能够认为是相似于HashMap的数据结构），通过一个哈希值索引，这个哈希值通过查问自身、以后要查问的数据库、客户端协定版本号等一些可能影响后果的信息计算得来。所以两个查问在任何字符上的不同（例如：空格、正文），都会导致缓存不会命中。 如果查问中蕴含任何用户自定义函数、存储函数、用户变量、长期表、mysql库中的零碎表，其查问后果都不会被缓存。比方函数NOW()或者CURRENT_DATE()会因为不同的查问工夫，返回不同的查问后果，再比方蕴含CURRENT_USER或者CONNECION_ID()的查问语句会因为不同的用户而返回不同的后果，将这样的查问后果缓存起来没有任何的意义。 既然是缓存，就会生效，那查问缓存何时生效呢？MySQL的查问缓存零碎会跟踪查问中波及的每个表，如果这些表（数据或构造）发生变化，那么和这张表相干的所有缓存数据都将生效。正因为如此，在任何的写操作时，MySQL必须将对应表的所有缓存都设置为生效。如果查问缓存十分大或者碎片很多，这个操作就可能带来很大的零碎耗费，甚至导致系统僵死一会儿。而且查问缓存对系统的额定耗费也不仅仅在写操作，读操作也不例外： 1.任何的查问语句在开始之前都必须通过查看，即便这条SQL语句永远不会命中缓存 2.如果查问后果能够被缓存，那么执行实现后，会将后果存入缓存，也会带来额定的零碎耗费 基于此，咱们要晓得并不是什么状况下查问缓存都会进步零碎性能，缓存和生效都会带来额定耗费，只有当缓存带来的资源节约大于其自身耗费的资源时，才会给零碎带来性能晋升。但要如何评估关上缓存是否可能带来性能晋升是一件十分艰难的事件，也不在本文探讨的领域内。如果零碎的确存在一些性能问题，能够尝试关上查问缓存，并在数据库设计上做一些优化，比方： 1.用多个小表代替一个大表，留神不要适度设计 2.批量插入代替循环单条插入 3.正当管制缓存空间大小，一般来说其大小设置为几十兆比拟适合 4.能够通过SQL_CACHE和SQL_NO_CACHE来管制某个查问语句是否须要进行缓存 最初的忠告是不要轻易关上查问缓存，特地是写密集型利用。如果你切实是忍不住，能够将query_cache_type设置为DEMAND，这时只有退出SQL_CACHE的查问才会走缓存，其余查问则不会，这样能够十分自在地管制哪些查问须要被缓存。 当然查问缓存零碎自身是非常复杂的，这里探讨的也只是很小的一部分，其余更深刻的话题，比方：缓存是如何应用内存的？如何管制内存的碎片化？事务对查问缓存有何影响等等，读者能够自行浏览相干材料，这里权当抛砖引玉吧。 语法解析和预处理　MySQL通过关键字将SQL语句进行解析，并生成一颗对应的解析树。这个过程解析器次要通过语法规定来验证和解析。比方SQL中是否应用了谬误的关键字或者关键字的程序是否正确等等。预处理则会依据MySQL规定进一步查看解析树是否非法。比方查看要查问的数据表和数据列是否存在等等。 查问优化　通过后面的步骤生成的语法树被认为是非法的了，并且由优化器将其转化成查问打算。少数状况下，一条查问能够有很多种执行形式，最初都返回相应的后果。优化器的作用就是找到这其中最好的执行打算。 MySQL应用基于老本的优化器，它尝试预测一个查问应用某种执行打算时的老本，并抉择其中老本最小的一个。在MySQL能够通过查问以后会话的last_query_cost的值来失去其计算以后查问的老本。 mysql> select * from t_message limit 10;...省略后果集 mysql> show status like 'last_query_cost';Variable_name  Value      Last_query_cost6391.799000　示例中的后果示意优化器认为大略须要做6391个数据页的随机查找能力实现下面的查问。这个后果是依据一些列的统计信息计算得来的，这些统计信息包含：每张表或者索引的页面个数、索引的基数、索引和数据行的长度、索引的散布状况等等。 有十分多的起因会导致MySQL抉择谬误的执行打算，比方统计信息不精确、不会思考不受其管制的操作老本（用户自定义函数、存储过程）、MySQL认为的最优跟咱们想的不一样（咱们心愿执行工夫尽可能短，但MySQL值抉择它认为老本小的，但老本小并不意味着执行工夫短）等等。 MySQL的查问优化器是一个非常复杂的部件，它应用了十分多的优化策略来生成一个最优的执行打算： 1.从新定义表的关联程序（多张表关联查问时，并不一定依照SQL中指定的程序进行，但有一些技巧能够指定关联程序） 2.优化MIN()和MAX()函数（找某列的最小值，如果该列有索引，只须要查找B+Tree索引最左端，反之则能够找到最大值，具体原理见下文） 3.提前终止查问（比方：应用Limit时，查找到满足数量的后果集后会立刻终止查问） 4.优化排序（在老版本MySQL会应用两次传输排序，即先读取行指针和须要排序的字段在内存中对其排序，而后再依据排序后果去读取数据行，而新版本采纳的是单次传输排序，也就是一次读取所有的数据行，而后依据给定的列排序。对于I/O密集型利用，效率会高很多） 随着MySQL的一直倒退，优化器应用的优化策略也在一直的进化，这里仅仅介绍几个十分罕用且容易了解的优化策略，其余的优化策略，大家自行查阅吧。 ...

问题概述应用阿里云rds for MySQL数据库（就是MySQL5.6版本），有个用户上网记录表6个月的数据量近2000万，保留最近一年的数据量达到4000万，查问速度极慢，日常卡死。重大影响业务。 问题前提：老零碎，过后设计零碎的人大略是大学没毕业，表设计和sql语句写的不仅仅是垃圾，几乎无奈直视。原开发人员都已到职，到我来保护，这就是传说中的保护不了就跑路，而后我就是掉坑的那个！！！ 我尝试解决该问题，so，有个这个日志。 计划概述计划一：优化现有mysql数据库。长处：不影响现有业务，源程序不须要批改代码，老本最低。毛病：有优化瓶颈，数据量过亿就玩完了。计划二：降级数据库类型，换一种100%兼容mysql的数据库。长处：不影响现有业务，源程序不须要批改代码，你简直不须要做任何操作就能晋升数据库性能，毛病：多花钱 计划三：一步到位，大数据解决方案，更换newsql/nosql数据库。长处：扩展性强，成本低，没有数据容量瓶颈，毛病：须要批改源程序代码 以上三种计划，按程序应用即可，数据量在亿级别一下的没必要换nosql，开发成本太高。三种计划我都试了一遍，而且都造成了落地解决方案。该过程心中慰问跑路的那几个开发者一万遍 :) 计划一具体阐明：优化现有mysql数据库跟阿里云数据库大佬电话沟通 and Google解决方案 and 问群里大佬，总结如下（都是精髓）： 1.数据库设计和表创立时就要思考性能2.sql的编写须要留神优化3.分区4.分表5.分库1.数据库设计和表创立时就要思考性能 mysql数据库自身高度灵便，造成性能有余，重大依赖开发人员能力。也就是说开发人员能力高，则mysql性能高。这也是很多关系型数据库的通病，所以公司的dba通常工资巨高。 设计表时要留神： 1.表字段防止null值呈现，null值很难查问优化且占用额定的索引空间，举荐默认数字0代替null。2.尽量应用INT而非BIGINT，如果非负则加上UNSIGNED（这样数值容量会扩充一倍），当然能应用TINYINT、SMALLINT、MEDIUM_INT更好。3.应用枚举或整数代替字符串类型4.尽量应用TIMESTAMP而非DATETIME5.单表不要有太多字段，倡议在20以内6.用整型来存IP索引 1.索引并不是越多越好，要依据查问有针对性的创立，思考在WHERE和ORDER BY命令上波及的列建设索引，可依据EXPLAIN来查看是否用了索引还是全表扫描2.应尽量避免在WHERE子句中对字段进行NULL值判断，否则将导致引擎放弃应用索引而进行全表扫描3.值散布很稀少的字段不适宜建索引，例如"性别"这种只有两三个值的字段4.字符字段只建前缀索引5.字符字段最好不要做主键6.不必外键，由程序保障束缚7.尽量不必UNIQUE，由程序保障束缚8.应用多列索引时主见程序和查问条件保持一致，同时删除不必要的单列索引简言之就是应用适合的数据类型，抉择适合的索引 抉择适合的数据类型 （1）应用可存下数据的最小的数据类型，整型 < date,time < char,varchar < blob （2）应用简略的数据类型，整型比字符解决开销更小，因为字符串的比拟更简单。如，int类型存储工夫类型，bigint类型转ip函数 （3）应用正当的字段属性长度，固定长度的表会更快。应用enum、char而不是varchar （4）尽可能应用not null定义字段 （5）尽量少用text，非用不可最好分表 # 抉择适合的索引列 （1）查问频繁的列，在where，group by，order by，on从句中呈现的列 （2）where条件中<，<=，=，>，>=，between，in，以及like 字符串+通配符（%）呈现的列 （3）长度小的列，索引字段越小越好，因为数据库的存储单位是页，一页中能存下的数据越多越好 （4）离散度大（不同的值多）的列，放在联结索引后面。查看离散度，通过统计不同的列值来实现，count越大，离散水平越高： 原开发人员曾经跑路，该表早已建设，我无奈批改，故：该措辞无奈执行，放弃！ 2.sql的编写须要留神优化 1.应用limit对查问后果的记录进行限定 2.防止select *，将须要查找的字段列出来 3.应用连贯（join）来代替子查问 4.拆分大的delete或insert语句 5.可通过开启慢查问日志来找出较慢的SQL 6.不做列运算：SELECT id WHERE age + 1 = 10，任何对列的操作都将导致表扫描，它包含数据库教程函数、计算表达式等等，查问时要尽可能将操作移至等号左边 7.sql语句尽可能简略：一条sql只能在一个cpu运算；大语句拆小语句，缩小锁工夫；一条大sql能够堵死整个库 8.OR改写成IN：OR的效率是n级别，IN的效率是log(n)级别，in的个数倡议管制在200以内 9.不必函数和触发器，在应用程序实现 10.防止%xxx式查问 11.少用JOIN 12.应用同类型进行比拟，比方用'123'和'123'比，123和123比 13.尽量避免在WHERE子句中应用!=或<>操作符，否则将引擎放弃应用索引而进行全表扫描 14.对于间断数值，应用BETWEEN不必IN：SELECT id FROM t WHERE num BETWEEN 1 AND 5 ...

前言每一个好习惯都是一笔财产，本文分SQL后悔药， SQL性能优化，SQL标准优雅三个方向，分享写SQL的21个好习惯，有不对的中央欢送斧正。 欢送进群973961276一起聊聊技术吹吹牛，每周都会有几次抽奖送专业书籍的流动，奖品不甚值钱，但也算个搏个彩头。谢谢浏览，加油哈~ 1. 写完SQL先explain查看执行打算（SQL性能优化）日常开发写SQL的时候，尽量养成这个好习惯呀：写完SQL后，用explain剖析一下，尤其留神走不走索引。 explain select * from user where userid =10086 or age =18; 2、操作delete或者update语句，加个limit(SQL后悔药）在执行删除或者更新语句，尽量加上limit，以上面的这条 SQL 为例吧： delete from euser where age > 30 limit 200; 因为加了limit 次要有这些益处： 升高写错SQL的代价, 你在命令行执行这个SQL的时候，如果不加limit，执行的时候一个不小心手抖，可能数据全删掉了，如果删错了呢？加了limit 200，就不一样了。删错也只是失落200条数据，能够通过binlog日志疾速复原的。SQL效率很可能更高，你在SQL行中，加了limit 1，如果第一条就命中指标return， 没有limit的话，还会继续执行扫描表。防止了长事务，delete执行时,如果age加了索引，MySQL会将所有相干的行加写锁和间隙锁，所有执行相干行会被锁住，如果删除数量大，会间接影响相干业务无奈应用。数据量大的话，容易把CPU打满 ,如果你删除数据量很大时，不加 limit限度一下记录数，容易把cpu打满，导致越删越慢的。设计表的时候，所有表和字段都增加相应的正文（SQL标准优雅）这个好习惯肯定要养成啦，设计数据库表的时候，所有表和字段都增加相应的正文，前面更容易保护。 正例： CREATE TABLE `account` (`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键Id',`name` varchar(255) DEFAULT NULL COMMENT '账户名',`balance` int(11) DEFAULT NULL COMMENT '余额',`create_time` datetime NOT NULL COMMENT '创立工夫',`update_time` datetime NOT NULL ON UPDATE CURRENT_TIMESTAMP COMMENT '更新工夫',PRIMARY KEY (`id`),KEY `idx_name` (`name`) USING BTREE) ENGINE=InnoDB AUTO_INCREMENT=1570068 DEFAULT CHARSET=utf8 ROW_FORMAT=REDUNDANT COMMENT='账户表'; ...

首先先简略的将一个查问语句背地MySQL做了什么捋一捋： 客户端发送一条查问给服务器。服务器先查看查问缓存，如果命中了缓存，则立即返回存储在缓存中的后果。否则进入下一个阶段。服务器端进行SQL解析，预处理，再由优化器生成对应的执行打算。MySQL依据优化器生成的执行打算，调用存储引擎的API来执行查问。将后果返回给客户端。 接着咱们就将这个过程中的这些步骤具体的进行开展。 1.客户端和服务器端之间的通信形式客户端和服务器之间的通信是一种半双工的通信，即在同一时刻，只能有一方向另一方发送数据。所以客户端在发送完查问申请之后，所能做的就是期待服务器将查问的后果返回，并且须要始终地等到返回的数据全副接管结束后能力进行下一步的操作，而不能够在服务器发送的过程中中断发送或者断开连接。 2.查问缓存在解析一个查问语句之前，如果查问缓存是关上着的，那么MySQL会优先查看这个查问是否命中查问缓存中的数据。这个查看是通过一个对大小写敏感的哈希表来实现的。在查问命中缓存的状况下，间接从缓存中拿到后果并返回给客户端。MySQL不会再执行上面的操作，即查问语句不会被解析，不会生成执行打算，不会被执行。 3.查问优化解决这个环节可能是整个查问执行过程中最为简单的一个环节，能够分为解析SQL，预处理和优化SQL执行打算三个步骤。 （1）语法解析器和预处理这个过程就是对咱们传入的SQL语句的语法进行查看，以及验证查问的权限。炳辉生成一棵“解析树”。 （2）查问优化器在进入到这一步时，证实咱们的语句语法层面曾经没有问题了。一条查问能够有很多种执行打算都能返回正确的后果，这个环节就是来选取最优的执行打算的。MySQL的最优执行打算是基于老本的。MySQL会为每个操作设定一个老本（如执行一次where比拟），并从所有的执行打算中抉择“老本”起码的。咱们能够应用下列语句查看上一个查问操作的老本： mysql> SHOW STATUS LIKE 'last_query_cost';MySQL会返回一个执行的老本数据： +-----------------+----------+| Variable_name | Value |+-----------------+----------+| Last_query_cost | 0.549000 |+-----------------+----------+但值得注意的是，这里的“老本”最小并不等于查问的速度最快。即以“老本”来判断查问语句的优劣有时候是不牢靠的。 优化器的优化策略能够大抵地分为两种：动态优化和动静优化。 动态优化是间接对之前生成的解析树进行剖析，例如能够通过一些代数变换将where条件转化为另一种等价模式。动态优化在第一次实现后就始终失效，即便应用不同的参数反复执行查问也不会发生变化，能够认为是一种“编译（预处理）时优化”。 动静优化和查问的上下文相干，须要在每一次查问的时候从新评估，能够认为是一种“运行时优化”。 上面是一些MySQL可能解决的优化类型： 从新定义关联表的程序有时候咱们所给的查问语句关联表的程序可能对于查问来说效率并不是最优的，这时候MySQL能够主动帮咱们将关联表的程序进行调整提高效率。 将外连贯转化为内连贯并不是所有的OUT JOIN语句都必须以外连贯的形式执行。MySQL可能辨认这一点并重写查问，让其能够调整关联程序。 应用等价变换规定应用一些等价的语句来缩小比拟的次数，移除一些恒成立和不恒成立的条件。例如，（5=5 AND a>5）会被改写为a>5;如果有(a5 AND b=c AND a=5。 优化COUNT()、MIN()和MAX()索引和列是否为空能够帮忙优化这一类表达式。例如查找最小值的时候就能够借助索引间接查找最左端的记录，这样就不必进行整个表的查问，而是以一个常数进行取代。 笼罩索引扫描当索引中的列蕴含所有查问中须要应用的列的时候，MySQL就会应用索引返回所须要的数据，而无须查问对应的数据行。 提前终止查问在发现查问曾经能满足需要的时候，MySQL总能立即终止查问。一个典型的例子就是当应用了LIMIT子句的时候。 至此，MySQL服务器层曾经依据所给的查问语句给出了一个最优的执行打算。然而咱们须要晓得的是，咱们到目前为止所进行的一些列的操作都是在服务器层进行的，而这一层中并不是数据存储的中央。因而接下来咱们须要拿着咱们的最优执行打算去到理论的存储引擎中进行查找。因而就引出了咱们的下一步操作：向存储引擎获取相应的统计信息。 4.查问执行引擎绝对于查问优化阶段，查问执行阶段并不是那么简单。MySQL只是简略地依据执行打算给出的指令逐渐执行。 5.返回后果给客户端查问执行的最初一个阶段是将后果返回给客户端，即便查问不须要返回后果集给客户端，MySQL依然会返回这个查问的一些信息，例如查问影响的行数。如果查问能够被缓存，这个阶段MySQL会讲查问的后果放到查问缓存中。返回后果的过程是一个逐渐增量的过程。即当拿到第一个后果的时候就开始向客户端返回了。这样做的益处是不会一次性返回全副数据导致占用内存过多，而且客户端也能在第一工夫拿到后果。后果集中的每一行都会以一个满足MySQL客户端/服务器通信协议的封包发送，再通过TCP协定进行传输，在TCP传输的过程中，可能对封包进行缓存后再批量发传输。

MySQL查问练习一1、查问student表中的所有记录； mysql> select * from student;+-----+-----------+------+---------------------+-------+| sno | sname | ssex | sbirthday | class |+-----+-----------+------+---------------------+-------+| 101 | 曾华 | 男 | 1977-09-01 00:00:00 | 95033 || 102 | 匡明 | 男 | 1975-10-02 00:00:00 | 95031 || 103 | 王丽 | 女 | 1976-01-23 00:00:00 | 95033 || 104 | 李军 | 男 | 1976-02-20 00:00:00 | 95033 || 105 | 王芳 | 女 | 1975-02-10 00:00:00 | 95031 || 106 | 陆君 | 男 | 1974-06-03 00:00:00 | 95031 || 107 | 王尼玛 | 男 | 1974-06-03 00:00:00 | 95031 || 108 | 张全蛋 | 男 | 1974-06-03 00:00:00 | 95031 || 109 | 赵铁柱 | 男 | 1974-06-03 00:00:00 | 95031 |+-----+-----------+------+---------------------+-------+9 rows in set (0.00 sec)2、查问student表中的所有记录的sname，ssex，class列； mysql> select sname, ssex, class from student;+-----------+------+-------+| sname | ssex | class |+-----------+------+-------+| 曾华 | 男 | 95033 || 匡明 | 男 | 95031 || 王丽 | 女 | 95033 || 李军 | 男 | 95033 || 王芳 | 女 | 95031 || 陆君 | 男 | 95031 || 王尼玛 | 男 | 95031 || 张全蛋 | 男 | 95031 || 赵铁柱 | 男 | 95031 |+-----------+------+-------+9 rows in set (0.00 sec)3、查问老师所有的单位即不反复的depart列；关键字distinct排除反复。 ...

前言： 在后面文章中，有提到过 mysqldump 备份文件中记录的工夫戳数据都是以 UTC 时区为根底的，在筛选复原单库或单表时要留神时区差异。起初再次查看文档，发现 tz-utc、skip-tz-utc 参数与此有关，本篇文章咱们一起来看下此参数的作用吧。 1.tz-utc与skip-tz-utc参数介绍这两个参数能够作用于 mysqldump 备份过程中，互为相同参数。顾名思义能够看出，一个参数是将工夫戳改为 UTC 时区，另一个是跳过期区变动。 在 mysql 服务器上执行 mysqldump --help 的命令，能够看到上面一段话。 [root@host ~]# mysqldump --helpmysqldump Ver 10.13 Distrib 5.7.23, for Linux (x86_64)Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved....省略很多内容 --tz-utc SET TIME_ZONE='+00:00' at top of dump to allow dumping of TIMESTAMP data when a server has data in different time zones or data is being moved between servers with different time zones. (Defaults to on; use --skip-tz-utc to disable.)--tz-utc 参数是 mysqldump 的默认参数，会使得 mysqldump 的导出文件的顶部加上一个设置时区的语句 SET TIME_ZONE='+00:00' ，这个时区是格林威治工夫，也就是0时区。这样当导出 timestamp 工夫戳字段时，会把在服务器设置的以后时区下显示的 timestamp 工夫值转化为在格林威治工夫下显示的工夫。比方咱们数据库采纳北京工夫东八区，mysqldump 导出的文件当中显示的 timestamp 工夫值绝对于通过数据库查问显示的工夫倒退了8个小时。 ...

一、写在结尾vivo 云服务提供给用户备份手机上的联系人、短信、便签、书签等数据的能力，底层存储采纳 MySQL 数据库进行数据存储。 随着 vivo 云服务业务倒退，云服务用户量增长迅速，存储在云端的数据量越来越大，海量数据给后端存储带来了微小的挑战。云服务业务这几年最大的痛点，就是如何解决用户海量数据的存储问题。 二、面临挑战2017-2018年，云服务产品外围指标着重于晋升用户量。云服务在产品策略上做了重大调整，用户登录 vivo 账号后默认开启云服务数据同步开关。 此产品策略给云服务用户量带来了爆发式的增长，用户量从百万级别间接跳跃至千万级别，后端存储的数据量也从百亿级别飞跃至千亿级别。 为了解决海量数据的存储问题，云服务将分库分表的 4 板斧：程度分表、垂直分表、程度分库、垂直分库，全副进行了实际。 1、程度分表荆棘之路 1：浏览器书签、便签单库单表，单表数据量已过亿级怎么办？置信理解过分库分表常识体系的兄弟很快可能答复：单表数据量过大那就进行分表。咱们也是如此做的，将浏览器书签、便签模块单表拆分至 100 张表。 将浏览器书签、便签单表亿级数据量迁徙至 100 张分表里，每张表承载 1000W 的数据量。 这就是大家相熟的第一板斧：程度分表。 2、程度分库荆棘之路 2：联系人、短信数据已分表，然而最后只分了 50 张表，未进行分库。用户量爆发式增长后，单库联系人总数据量已达到 几十亿，单表数据量已高达5000W ,持续增长将重大影响mysql性能，怎么办？第二板斧，程度分库：1个库撑持不住，那就多分几个库。咱们将原来单库拆分成10个库，并且将原来单库联系人、短信50张表扩大至100张表，同样期间进行了几十亿存量数据的迁徙重路由，非常苦楚。 3、垂直分库、垂直分表荆棘之路3：最后云服务各个模块的数据存储都繁杂在一起。当空间存在瓶颈后，咱们对各模块数据的存储空间散布进行了剖析，状况如下： 单库磁盘容量5T，联系人数据占用存储空间2.75T（55%），短信数据占用存储空间1T（20%），其余所有模块数据共占用存储空间500G(5%)，残余可用空间1T， 联系人、短信数据即占用了总空间的75%。  残余1T的空间容量是无奈撑持用户数据的持续增长,状况不容乐观。若空间有余，所有模块都会因为空间问题导致不可用，怎么办？ （下图为云服务过后的数据存储空间分布图） 第三、四板斧，垂直分库、垂直分表：咱们将联系人数据、短信数据和其余模块数据进行存储解耦。将联系人数据、短信数据都独自拆分成库。 至此，云服务将分库分表的 4 板斧全副实际了一遍，数据该拆的拆，该分的分。 4、基于路由表的动静扩容计划荆棘之路4：从上述形容得悉拆分进去的联系人数据库采纳固定10个库的分库策略，后期评估10库*100张表是能够满足业务数据增长需要的，本认为能够居安思危，然而联系人数据增长速率超出了预期。联系人数据库独自拆分9个月之后，单个库的存储空间从35%增长至65%。依照这个增长速度，再撑持6个月，独立拆分进去的联系人数据库将再次面临空间有余问题。 如何解决？持续扩容是必定的，外围点在于采纳哪种扩容策略。如果采纳惯例的扩容计划，那咱们将面临着海量存量数据的迁徙从新路由问题，老本太大。 通过技术组沟通探讨，联合云服务联系人业务的本身个性（老用户的联系人数量基本上是稳固的，不会频繁的增加大量的联系人,老用户联系人数据增长的速率可控），咱们最终采纳了基于路由表的动静扩容计划。 以下介绍下此计划特点： 增加用户路由表，记录用户联系人数据具体路由在哪个库，哪张表；新用户的联系人数据会路由到新扩容的数据库里，不会对原有老库造成数据存储压力。老用户的数据不会动，还是保留在原来的数据库。此计划的特点是保障了原有老库只需保障老用户的数据增长即可，新用户全副由新扩容的库来承载。 老用户联系人的增长速率尽管可控，但咱们冀望原老库能预留60%的存储空间来撑持老用户的数据增长。目前老库只残余35%的可用空间，不合乎咱们的要求。 为了升高老库数据占用的存储空间，自然而然咱们想到了从数据压缩层面着手。 三、压缩计划预研云服务对数据库数据压缩进行了以下3种计划的预研： 计划1：程序自行实现数据压缩，压缩后再保留至数据库 劣势： 无需对数据库进行任何革新，批改齐全由程序本人收敛，能够自在管制须要进行压缩的字段。劣势： 存量数据须要开发额定的压缩工作进行数据压缩，且存量数据量级过大，靠程序进行数据压缩耗时不可控。数据压缩入库后，须要从db平台间接进行select查问字段的内容不再是可读的，加大了后续定位问题的难度。 计划2：MySQL 数据库 InnoDB 自带的数据压缩能力 劣势： 利用 InnoDB 已有的能力进行数据压缩，对于下层程序无需做任何革新，且不影响后续select数据查问。劣势： 实用于数据量较大，读多写少的业务场景，且对要求高查问性能的业务不太适合。计划3：切换InnoDB 存储引擎至TokuDB，利用TokuDB引擎人造的数据压缩能力 劣势： TokuDB人造反对数据压缩，并且反对多种压缩算法，反对频繁的数据写入场景，对于大数据量的存储有人造的劣势。劣势： MySQL 须要装置额定的插件对TokuDB引擎进行反对，且公司目前没有业务有TokuDB成熟的应用教训，接入后的危险未知，对后续 DBA 的保护也是一项挑战。咱们通过综合思考，最终决定采纳第二种压缩计划：InnoDB自有的压缩能力。 ...

写在后面最近在写Mycat专题，因为不少小伙伴最近要进来面试，问我能不能简略写下MySQL的主从复制原理和注意事项，因为在之前的面试中被问到了这些问题。我：能够啊，安顿上了！！主从复制原理(1) Master 将数据扭转记录到二进制日志(binary log)中，也就是配置文件 log-bin 指定的文件， 这些记录叫做二进制日志事件(binary log events)； (2) Slave 通过 I/O 线程读取 Master 中的 binary log events 并写入到它的中继日志(relay log)； (3) Slave 重做中继日志中的事件，把中继日志中的事件信息一条一条的在本地执行一次，完 成数据在本地的存储，从而实现将扭转反映到它本人的数据(数据重放)。 注意事项(1)主从服务器操作系统版本和位数统一； (2) Master 和 Slave 数据库的版本要统一； (3) Master 和 Slave 数据库中的数据要统一； (4) Master 开启二进制日志，Master 和 Slave 的 server_id 在局域网内必须惟一； 配置主从复制步骤Master数据库(1) 装置数据库； (2) 批改数据库配置文件，指明 server_id，开启二进制日志(log-bin)； (3) 启动数据库，查看以后是哪个日志，position 号是多少； (4) 登录数据库，受权数据复制用户（IP 地址为从机 IP 地址，如果是双向主从，这里的 还须要受权本机的 IP 地址，此时本人的 IP 地址就是从 IP 地址)； (5) 备份数据库（记得加锁和解锁）； ...

一、需要 一个敌人接到一个需要，从大数据平台收到一个数据写入在20亿+，须要疾速地加载到MySQL中，供第二天业务展现应用。 二、实现再剖析 对于单表20亿， 在MySQL运维，说真的这块目前波及得比拟少，也根本没什么教训，但对于InnoDB单表Insert 如果内存大于数据状况下，能够维持在10万-15万行写入。 但很多工夫咱们承受的我的项目还是数据超过内存的。 这里应用XeLabs TokuDB做一个测试。 三、XeLabs TokuDB介绍 我的项目地址： https://github.com/XeLabs/tokudb 绝对官网TokuDB的优化： 内置了jemalloc 内存调配；引入更多的内置的TokuDB性能指标；反对Xtrabackup备份；引入ZSTD压缩算法；反对TokuDB的binlog_group_commit个性；四、测试表 TokuDB外围配置： 表构造： 利用load data写入数据： 计算一下每秒写入速度： 文件大小： 理论文件8.5G，写入TokuDB大小3.5G，只是靠近于一半多点的压缩量。 对于20亿数据写入，理论测试在58分钟多点就能够实现。能够满足理论需要，另外对于磁盘IO比拟好的机器（SSD类盘，云上的云盘），如果内存和数据差不多状况，这量级数据量测试在Innodb里须要增加自增列，能够在3个小多一点实现。 从最佳实战上来看，Innodb和TokuDB都写入同样的数据，InnoDB须要花大略是TokuDB3-4倍工夫。文件大小区别，同样20亿数据： 文件大小在5倍大小的区别。 测试论断： 利用TokuDB在某云环境中8核8G内存，500G高速云盘环境，屡次测试能够轻松实现57万每秒的写入量。 另外测试几种场景也供大家参考： 如果在TokuDB中应用带自增的主键，主键无值让MySQL外部产生写入速度，降落比拟显著，同样写入2亿数据，带有自建主键： 同样的数据写入在主键自增无值产生时，不能应用TokuDB的 Bulk loader data个性，相当于转换为了单条的Insert实现，所以成果上慢太多。 对于TokuDB Bulk Loader前提要求，这个表是空表，对于自增列，如自增列有值的状况下，也能够应用。 倡议理论应用中，如果自增列有值的状况下，能够思考去除自增属性，改成惟一索引，这样缩小自增的一些解决逻辑，让TokuDB能跑地更快一点。 另外在Bulk Loader解决中为了谋求更疾速的写入，压缩方面并不是很好。 对于TokuDB Bulk Loader : https://github.com/percona/Pe... 五、测试环境阐明 测试应用CentOS7环境 本文作者：吴炳锡起源：https://yq.aliyun.com/article...

在MySQL优化的环节上，咱们首先须要晓得的就是咱们以后的这句SQL语句在理论的数据库中到底是怎么执行的，能力谈要如何优化它。而在MySQL中，就给咱们提供了模仿语句执行的一个十分好用的关键字：EXPLAIN。EXPLAIN能够用来查看SQL语句的执行成果，能够帮忙抉择更好的索引和优化查问语句，写出更好的优化语句。因而明天咱们就来讲一讲这个关键字的一些根底的用法与利用。 一、应用办法EXPLAIN的应用办法非常简单： mysql> EXPLAIN SELECT * FROM user;简略来说，就是在原有的SQL语句后面加上EXPLAIN关键字，或者说是在EXPLAIN关键字后跟这你要查看的SQL语句。 二、输入后果EXPLAIN语句的输入后果才是咱们想要的数据，也是咱们剖析的重点。咱们先来看看下面的语句所给到的对应的后果的模式： +----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+| 1 | SIMPLE | user | NULL | ALL | NULL | NULL | NULL | NULL | 3 | 100.00 | NULL |+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+EXPLAIN语句给到咱们的数据总共有10列，接下来咱们看一下一些在性能优化上有比拟重要作用的数据列所代表的意思。 1.id这个是select查问的序列号。 2.select_type当咱们的SQL语句是非select语句的时候（即delete，update...），这个字段的值就是对应的操作类型（delete，update...）。 mysql> EXPLAIN INSERT INTO user VAULES(2,'ahong','31');此时的输入select_type就是咱们对应的INSERT： ...

SQL面试题 **1. DDL ：数据定义语言 create table .../ drop table ... / rename ... to..../ truncate table.../alter table ...DML : 数据操纵语言**insert into ... values ... update ... set ... where ... delete from ... where ... 2. select 查问后果 如: [学号,均匀问题：组函数avg(问题)] _from_ 从哪张表中查找数据 如:[波及到问题：成绩表score] _where_ 查问条件 如:[b.课程号='0003' and b.问题>80] _group by_ 分组 如:每个学生的均匀：按学号分组,MySQL中能够不必 _having_ 对分组后果指定条件 如:[大于60分] _order by_ 对查问后果排序 如:[增序: 问题 ASC / 降序: 问题 DESC];** limit 应用limt子句返回topN（对应这个问题返回的问题前两名）如:[ limit 2 _==>从0索引开始读取2个_] limit==>从0索引开始 [0,N-1] ...

1.下载MariaDB数据库测试：以后虚拟机是否能够失常的链接外网。命令： 2 确认下载 3 装置实现提醒 4 数据库启动命令: 5. 数据库初始化操作命令: mysql_secure_installation 6.测试数据库用户名和明码是否无效 7.导入数据表阐明:如果mysql数据库须要导入数据表命令如下:命令: source /xxx/xxxx/xxxx/jtdb.sql 8.Mysql数据库近程拜访配置 8.1 对于链接数据库的阐明阐明: 如果须要近程链接数据库必须通过防火墙如果近程链接数据库,数据库中必须开启近程拜访权限才行,否则回绝链接.8.2 配置数据库权限配置阐明 8.3 配置Linux数据库权限8.3.1 切换数据库mysql切换Mysql数据库 8.3.2 批改数据库表1)。查看数据表2).查问user表中的host/root/password3).将host="localhost"改为"%"4).刷新数据库权限 9. 配置Linux防火墙策略9.1 查看防火墙状态命令: firewall-cmd --state 9.2 防火墙配置阐明:防火墙中有一个配置文件,示意当Linux系统启动时防火墙应该如何操作!!!需要: 通知linux零碎当前开机不须要启动防火墙命令: systemctl disable firewalld.servicesystemctl enable firewalld.service 9.3 手动敞开防火墙阐明:通过命令手动将防火墙敞开命令: systemctl stop firewalld.servicesystemctl start firewalld.service 9.4 手动凋谢防火墙端口1). 查看防火墙凋谢的端口2).查看端口是否凋谢3). 开启防火墙4).移除端口5).对于防火墙操作的解释–zone #作用域 –add-port=80/tcp #增加端口，格局为：端口/通信协定 –remove-port=80/tcp #移除端口，格局为：端口/通信协定 –permanent #永恒失效，没有此参数重启后生效 6).重启防火墙 9.4 数据库近程测试 9.5 导入jtdb.sql

1、终端操作MySQL数据库1.1如何登陆数据库服务器：C:Usersusername>mysql -uroot -proot 1.2如何查询数据库服务器中的数据库mysql> show databases;+--------------------+| Database |+--------------------+| information_schema || mysql || performance_schema || sys || test1 |+--------------------+5 rows in set (0.03 sec)1.3如何选中某一个数据库进行操作mysql> use test1Database changed1.4SQL语句中的查问mysql> select * from person;+-----------+------+| name | sex |+-----------+------+| 张三 | 男 || 李四 | 女 || 王麻子 | 男 |+-----------+------+3 rows in set (0.00 sec)mysql> select * from person where name="张三";+--------+------+| name | sex |+--------+------+| 张三 | 男 |+--------+------+1 row in set (0.00 sec)1.5如何退出数据库服务器mysql> exit;Bye 2、如何创立数据库数据表2.1如何在数据库服务器中创立咱们的数据库mysql> create database test2;Query OK, 1 row affected (0.05 sec)mysql> show databases;+--------------------+| Database |+--------------------+| information_schema || mysql || performance_schema || sys || test1 || test2 |+--------------------+6 rows in set (0.00 sec)mysql> use test2;Database changed2.2如何查看某个数据库中的所有数据表mysql> show tables;Empty set (0.00 sec)2.3如何创立一个数据表mysql> create table pet( -> name VARCHAR(20), -> owner VARCHAR(20), -> species VARCHAR(20), -> sex CHAR(1), -> birth DATE, -> death DATE);Query OK, 0 rows affected (0.09 sec)创立了一个宠物数据表 ...

目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完满范式）。而通常咱们用的最多的就是第一范式（1NF）、第二范式（2NF）、第三范式（3NF），也就是本文要讲的“三大范式”。。 而通常咱们用的最多的就是第一范式（1NF）、第二范式（2NF）、第三范式（3NF），也就是本文要讲的“三大范式”。 第一范式（1NF）：要求数据库表的每一列都是不可分割的原子数据项。 举例说明： 在下面的表中，“家庭信息”和“学校信息”列均不满足原子性的要求，故不满足第一范式，调整如下： 可见，调整后的每一列都是不可再分的，因而满足第一范式（1NF）； 第二范式（2NF）：在1NF的根底上，非码属性必须齐全依赖于候选码（在1NF根底上打消非主属性对主码的局部函数依赖） 第二范式须要确保数据库表中的每一列都和主键相干，而不能只与主键的某一部分相干（次要针对联结主键而言）。 举例说明： 在上图所示的状况中，同一个订单中可能蕴含不同的产品，因而主键必须是“订单号”和“产品号”联结组成， 但能够发现，产品数量、产品折扣、产品价格与“订单号”和“产品号”都相干，然而订单金额和订单工夫仅与“订单号”相干，与“产品号”无关， 这样就不满足第二范式的要求，调整如下，需分成两个表：     第三范式（3NF）：在2NF根底上，任何非主属性不依赖于其它非主属性（在2NF根底上打消传递依赖） 第三范式须要确保数据表中的每一列数据都和主键间接相干，而不能间接相干。 举例说明： 上表中，所有属性都齐全依赖于学号，所以满足第二范式，然而“班主任性别”和“班主任年龄”间接依赖的是“班主任姓名”， 而不是主键“学号”，所以需做如下调整：    这样以来，就满足了第三范式的要求。 ps:如果把上表中的班主任姓名改成班主任教工号可能更确切，更符合实际状况，不过只有能了解就行。

索引和锁是数据库中的两个外围知识点，隔离级别的实现都是通过锁来实现的 依照锁颗粒对锁进行划分 ？锁用来对数据进行锁定，咱们能够从锁定对象的粒度大小来对锁进行划分，别离为行锁、页锁和表锁。 行锁就是依照行的粒度对数据进行锁定。锁定力度小，产生锁抵触概率低，能够实现的并发度高，然而对于锁的开销比拟大，加锁会比较慢，容易呈现死锁状况。页锁就是在页的粒度上进行锁定，锁定的数据资源比行锁要多，因为一个页中能够有多个行记录。当咱们应用页锁的时候，会呈现数据节约的景象，但这样的节约最多也就是一个页上的数据行。页锁的开销介于表锁和行锁之间，会呈现死锁。锁定粒度介于表锁和行锁之间，并发度个别。表锁就是对数据表进行锁定，锁定粒度很大，同时产生锁抵触的概率也会较高，数据拜访的并发度低。不过益处在于对锁的应用开销小，加锁会很快。还有区锁和数据库锁. 每个层级的锁数量是有限度的，因为锁会占用内存空间，锁空间的大小是无限的。当某个层级的锁数量超过了这个层级的阈值时，就会进行锁降级。锁降级就是用更大粒度的锁代替多个更小粒度的锁，比方 InnoDB 中行锁降级为表锁，这样做的益处是占用的锁空间升高了，但同时数据的并发度也降落了。 从数据库治理的角度对锁进行划分共享锁和排它锁 共享锁也叫读锁或 S 锁，共享锁锁定的资源能够被其余用户读取，但不能批改。在进行SELECT的时候，会将对象进行共享锁锁定，当数据读取结束之后，就会开释共享锁，这样就能够保证数据在读取时不被批改。 排它锁也叫独占锁、写锁或 X 锁。排它锁锁定的数据只容许进行锁定操作的事务应用，其余事务无奈对已锁定的数据进行查问或批改。 当咱们对数据进行更新的时候，也就是INSERT、DELETE或者UPDATE的时候，数据库也会主动应用排它锁，避免其余事务对该数据行进行操作。 意向锁（Intent Lock），简略来说就是给更大一级别的空间示意外面是否曾经上过锁。 从程序员的角度对锁进行划分乐观锁乐观锁（Optimistic Locking）认为对同一数据的并发操作不会总产生，属于小概率事件，不必每次都对数据上锁，也就是不采纳数据库本身的锁机制，而是通过程序来实现。在程序上，咱们能够采纳版本号机制或者工夫戳机制实现。 乐观锁的版本号机制在表中设计一个版本字段 version，第一次读的时候，会获取 version 字段的取值。而后对数据进行更新或删除操作时，会执行UPDATE ... SET version=version+1 WHERE version=version。此时如果曾经有事务对这条数据进行了更改，批改就不会胜利。 乐观锁的工夫戳机制工夫戳和版本号机制一样，也是在更新提交的时候，将以后数据的工夫戳和更新之前获得的工夫戳进行比拟，如果两者统一则更新胜利，否则就是版本抵触。 乐观锁乐观锁（Pessimistic Locking）也是一种思维，对数据被其余事务的批改持激进态度，会通过数据库本身的锁机制来实现，从而保证数据操作的排它性。 实用场景乐观锁适宜读操作多的场景，相对来说写的操作比拟少。它的长处在于程序实现，不存在死锁问题，不过实用场景也会绝对乐观，因为它阻止不了除了程序以外的数据库操作。乐观锁适宜写操作多的场景，因为写的操作具备排它性。采纳乐观锁的形式，能够在数据库层面阻止其余事务对该数据的操作权限，避免读 - 写和写 - 写的抵触。总结乐观锁和乐观锁并不是锁，而是锁的设计思维。 防止死锁的产生： 如果事务波及多个表，操作比较复杂，那么能够尽量一次锁定所有的资源，而不是逐渐来获取，这样能够缩小死锁产生的概率；如果事务须要更新数据表中的大部分数据，数据表又比拟大，这时能够采纳锁降级的形式，比方将行级锁降级为表级锁，从而缩小死锁产生的概率；不同事务并发读写多张数据表，能够约定拜访表的程序，采纳雷同的程序升高死锁产生的概率

理论工作和生存中，经常遇到以下问题：如何让任何中央都能拜访本人家里的笔记本上的利用？如何让局域网的服务器能够被任何中央拜访到？如何在异地近程解决公司服务问题；企业员工如何在异地拜访公司内网财务/管理系统，能够随时上传下载文档等；对于没有公网 IP 的用户来说，远程管理或在外网拜访内网机器上的服务是一个问题，有很多相似的需要；集体开发者程序员，对微信公众号小程序也须要开发调试等，那么这些问题有什么解决方案呢？ 同类型的问题有很多，然而也有简略解决的办法。大多局部用户无非是没有公网ip，也没有工夫本人去搭建一款相似的软件，网上有很多开源的，测试后也很不尽人意。国内企业级的服务商有闪库和网云穿，身边共事包含很多敌人都在应用，配置较简略，简略讲下测评过的闪库的应用办法和注意事项，不懂得能够看以下图示： 简略来说，我是用于在家近程拜访公司电脑，能够近程管制拜访下接口，上传下文件之类的；远程桌面的话配置如下： 咱们先关上下载软件，关上官网是这样的 2、下载后咱们解压双击运行，免装置的 3、运行客户端，没有注册的先注册下账号 4、注册完登录进去，咱们依据提醒操作。 5、把隧道信息填写残缺，以3389远程桌面为例： 隧道名字：自定义 内网ip：本机ip，个别为127.0.0.1 内网端口：3389 依据本人利用填写相应的端口 6、配置完点击确定，会看到软件调配了一个外网地址，外网端口也主动显示 http模式，就间接拜访这个映射地址，外网端口默认80.tcp协定的服务咱们就加上外网端口去连贯。 7、最初咱们来测试下，近程是否胜利。 关上电脑自带的远程桌面，输出映射地址 8、能够看到，已胜利连贯远程桌面。 综上是对闪库的测评，是一个新软件，收费的10mbps带宽反对http、tcp。是一款国内的软件，这个也是软件他是能够公有部署再服务器，比拟不便，免费版是集体测试远程桌面，根本够用了。隧道采纳的是双向加密传输的，全协定反对 ，提供公网ip，应用了几天，总体不错，比一些免费的要强，这里不多说，测评全是集体亲自体验！

摘要：在全球化沟通交流如此亲密的时代，人们渴望通过地图理解到的不仅是简略的幅员轮廓，而是简单又宏大的实时动静地理信息。现在国家地理信息公共服务平台携手华为云，构建了“云上地图”，让世界触手可及。一起来一探到底吧！以前，家家户户都会挂着一张中国地图和世界地图，很多人对世界的概念也源于那一方轮廓，小小地图记录了整个世界的山川河流、城市人文，也撩动了咱们对世界的好奇心。 现在，随着科技的倒退，纸质地图逐步退出了咱们的生存，取而代之的是存于手机、电脑等各种模式的电子地图，查路线、看世界，各种信息触手所及。因而，获取各种丰盛的天文内容和实时动静信息，成为现代人广泛的地理信息诉求。哪里有需要，哪里就会有响应，国家地理信息公共服务平台天地图（以下简称“天地图”）表演的就是这么一个角色。 天地图是网络化地理信息共享与服务门户，集成了全国各省市和相干业余部门的地理信息资源，向各类用户提供权威、规范、对立的在线地理信息服务。随着国家、省、市根底测绘成绩积攒和天文信息产业的迅速倒退，以及数据获取能力的增强，地理信息成绩极为丰盛。但因不足为企业与公众在线服务的产品、跨尺度跨区域数据集成共享艰难等因素，地理信息集成服务能力有余，限度了天地图进一步为社会服务的能力。 云+5G+AI时代的到来，万物皆可上云，天地图也将眼光锁在了云上，决定携手华为云数据库将原先自建的数据库搬到华为云上，以提供更优质高效的服务。 天地图&华为云，彰显云上“数字中国”新魅力华为云数据库携手天地图联结打造“云+地图”的单干模式，推动地理信息共享、智能数据服务的突破性翻新，极大晋升了天地图的服务能力，彰显“数字中国”的古代魅力。 极速交融，迁徙疾如风 天地图全库数据量达到17TB，若延用线下计划迁徙，全副复原须要15天，而天地图承载着及时为公众提供各种地理信息服务的使命，无奈承受这么长的迁徙时长。思考到数据库迁徙品质和进度，华为云数据库决定采纳多种数据库引擎交融解决方案，确保各类数据无脱漏、易使用。 华为云GaussDB NoSQL服务反对高达100TB的海量数据存储，能够用来寄存占用空间极大的地理信息底图瓦片数据，轻松存储无压力。云数据库RDS for PostgreSQL增强版（GIS插件）寄存地理信息矢量数据，以提供及时精确的空间地理信息。RDS for MySQL寄存用户信息和图层配置信息，保障用户数据的稳固牢靠。多款数据库极速交融，独特发力，17TB的海量数据迁徙仅仅用了2天。 秒级扩容，拜访so easy 天地图为30+部委机构和全国30多个省市提供地理信息根底平台服务，提供了44项在线数字化地理信息业余服务，日均API和服务调用超过4亿次，拜访压力极大。 华为云数据库采纳最新一代高扩大海量存储分布式数据库GaussDB NoSQL来分担化解高拜访压力，可实现分钟级节点扩容和秒级存储扩容，扩容性能晋升百倍，满足麻利业务弹性须要，对天地图高达上亿的拜访毫无压力，响应能力快稳准，用户获取信息及时精确，无效保障了天地图在高负载情景下业务的失常运行。 多层管控，平安释怀间 作为国家级的服务平台，数据的安全可靠至关重要。华为云数据库GaussDB NoSQL跨AZ高可用，领有欠缺的跨区域容灾策略，故障呈现时可秒级复原，而且每天对数据库进行全量备份和增量备份，数据存储最长732天，并定期进行复原演练，验证备份复原流程的有效性，实现分钟级备份复原，确保天地图数据无失落，业务运行安全可靠。 小小一张“云上地图”囊括四海八荒，凝聚着智慧，闪耀着科技之光。此次天地图携手华为云数据库，为公众提供了更为全面、精准、权威、 智能、人性化的地理信息服务，让全社会共享测绘倒退成绩，感触“数字中国”的独特魅力。以后该我的项目曾经开始二期建设，并持续推广给全国30多个省市。 值此华为云11·11上云嘉年华之际，云数据库专场MySQL、PostgreSQL等多款产品低至2折，ECS+MySQL组合购还可享折上9折！深度分析行业痛点，提供全套解决方案，助力企业数字化转型。流动期间注册即领11110元大礼包，还有下单抽MateBook X Pro、看直播赢华为Mate 40等多重福利等您！更多惊喜猛戳→ 点击关注，第一工夫理解华为云陈腐技术~

阐明： • 本文档以“CentOS7.5”操作系统为例，对应MySQL版本为5.6.50• CentOS 7及以上版本将MySQL数据库软件从默认的程序列表中移除，需执行sudo rpm -Uvh http://dev.mysql.com/get/mysql-community-release-el7-5.noarch.rpm 进行手动下载。下载实现后可依照2进行装置。执行以下命令，装置MySQL数据库服务器、MySQL客户端和MySQL开发所需的库及蕴含文件。 yum install -y mysql-server mysql mysql-devel回显如下，阐明装置胜利。 Complete! 配置MySQL执行以下命令，启动MySQL服务。 service mysqld start执行以下命令，设置数据库管理员账号密码。明码由用户自定义，以Huawei@123为例进行阐明。mysqladmin -u root password 'Huawei@123'执行以下命令，再依据提醒输出数据库管理员root账号的明码进入数据库。 mysql -u root -p执行以下命令，应用MySQL数据库。 use mysql执行以下命令，查看用户列表。 select host,user from user; 阐明： 此命令及以下数据库语句均以分号结尾，请勿疏忽。执行以下命令，刷新用户列表并容许所有IP对数据库进行拜访。 update user set host='%' where user='root' LIMIT 1;执行以下命令，强制刷新权限。容许同一子网中设置为容许拜访的云服务器通过公有IP对MySQL数据库进行拜访。 flush privileges;执行以下命令，退出数据库。 quit执行以下命令，重启MySQL服务。 systemctl restart mysql执行以下命令，设置开机主动启动MySQL服务。 systemctl enable mysqld执行以下命令，敞开防火墙。 systemctl stop firewalld执行以下命令，设置服务器重启后永恒敞开防火墙。 systemctl disable firewalld来自 https://support.huaweicloud.c...

1.创立一个新的Linux 查看ip addr 并批改ip 成192.168.126.130找到ip 地址目录 cd /etc/sysconfig/network-scripts/找到第一个文件 ifcfg-ens33vim ifcfg-ens33 找到ipaddr 批改成 192.168.126.130保留后 重新启动服务 为了保障2台虚拟机失常稳固的运行,须要批改mac地址 在mobaXtern 或者xshell外面 创立一个新的.130的 连贯2.下载和装置 mariadb 命令：yum install mariadb-server开启mariadb 命令：systemctl start mariadb 找到src目录输出命令：用来配置数据库初始化 设置一些操作 3.批改拜访权限 和敞开防火墙https://segmentfault.com/a/1190000037768518参考mariadb 装置4.配置主库 和从库 默认条件数据库是不能是主库的 须要开启数据库二进制文件 当然 主库跟从库都须要批改 命令：vim /etc/my.cnf主库 批改增加成server-id=1 从库 server-id=2批改完了重启 数据库5.在数据库的主库外面 执行SHOW MASTER STATUS 查看 在从库中执行操作一：CHANGE MASTER TO MASTER_HOST="192.168.126.130",MASTER_PORT=3306,MASTER_USER="root",MASTER_PASSWORD="root",MASTER_LOG_FILE="mysql-bin.000003",MASTER_LOG_POS=245;这里 是在主库中SHOW MASTER STATUS 后 position是 245file 是 .000003 从库里 host写主库的ip 这里在从库中执行操作一后 操作二：START SLAVE;操作三：SHOW SLAVE STATUS;这样算胜利 如果出错 看前面有报错 执行STOP SLAVE 纠错以上实现了数据库的主从装置 ...

对很多开发者来说，数据库就是个黑盒子，你会写 SQL，会用数据库，但不晓得盒子外面到底是怎么一回事儿，这样你只能机械地去记住他人通知你的那些优化规定，却不晓得为什么要遵循这些规定，也就谈不上灵活运用。 数据库的服务端，能够划分为执行器 (Execution Engine) 和存储引擎 (Storage Engine) 两局部。 执行器负责解析 SQL 执行查问存储引擎负责保留数据。SQL是如何在执行器中执行的 ？咱们通过一个例子来看一下，执行器是如何来解析执行一条 SQL 的。 这个 SQL 语义是，查问用户 ID 大于 50 的用户的所有订单，这是很简略的一个联查，须要查问 users 和 orders 两张表，WHERE 条件就是，用户 ID 大于 50。 数据库收到查问申请后，须要先解析 SQL 语句，把这一串文本解析成便于程序处理的结构化数据: 转换后的结构化数据，就是一棵树，这个树的名字叫形象语法树（AST，Abstract Syntax Tree）。下面这个 SQL，它的 AST 大略是这样的： 这个树太简单，我只画了次要的局部，你大抵看一下，能了解这个 SQL 的语法树长什么样就行了。执行器解析这个 AST 之后，会生成一个逻辑执行打算。所谓的执行打算，能够简略了解为如何一步一步地执行查问和计算，最终失去执行后果的一个分步骤的打算。这个逻辑执行打算是这样的： 和 SQL、AST 不同的是，这个逻辑执行打算曾经很像能够执行的程序代码了。你看下面这个执行打算，很像咱们编程语言的函数调用栈，外层的办法调用内层的办法。所以，要了解这个执行打算，得从内往外看。 最内层的 2 个 LogicalTableScan 的含意是，把 USERS 和 ORDERS 这两个表的数据都读出来。而后拿这两个表所有数据做一个 LogicalJoin，JOIN 的条件就是第 0 列 (u.id) 等于第 6 列 (o.user_id)。而后再执行一个 LogicalFilter 过滤器，过滤条件是第 0 列 (u.id) 大于 50。最初，做一个 LogicalProject 投影，只保留第 0(user_id)、1(user_name)、5(order_id) 三列。这里“投影 (Project)”的意思是，把不须要的列过滤掉。把这个逻辑执行打算翻译成代码，而后依照程序执行，就能够正确地查问出数据了。然而，依照下面那个执行打算，须要执行 2 个全表扫描，而后再把 2 个表的所有数据做一个 JOIN 操作，这个性能是十分十分差的。 ...