企业官网建设流程全解析

东莞市专注网站建设平台,做自己网站彩票,wordpress 编辑自己代码,怎么打广告宣传自己的产品一、MySQL体系结构连接层、服务层、引擎层、存储层连接层 超市大门 收银员作用#xff1a;负责接待 “顾客”#xff08;客户端#xff0c;比如 Workbench、你的 Java 程序#xff09;#xff0c;验证身份#xff08;核对用户名密码#xff09;#xff0c;给顾客分配…一、MySQL体系结构连接层、服务层、引擎层、存储层连接层 超市大门 收银员作用负责接待 “顾客”客户端比如 Workbench、你的 Java 程序验证身份核对用户名密码给顾客分配 “购物车”数据库连接。通俗举例你进超市要先过门禁收银员确认你是合法顾客然后给你推车你才能开始逛。没有这一步你连超市门都进不去。2. 服务层 超市导购员 调度中心作用帮你规划 “购物路线”优化 SQL 执行计划告诉你东西在哪解析 SQL 语法核对你有没有买东西的权限权限校验最后帮你整理买好的商品处理查询结果。通俗举例你说 “我要买牛奶和面包”导购员直接带你去乳制品区和烘焙区不会让你瞎逛同时确认你带了钱有权限最后帮你把东西装袋。所有 “动脑子” 的活都在这一层。3. 引擎层 超市货架管理员作用负责具体的 “货位管理”数据存储和读取不同货架有不同的摆放规则对应不同存储引擎。比如有的货架InnoDB支持 “退货换货”事务、行锁有的货架MyISAM只卖特价商品不支持退换适合只读场景。通俗举例导购员让货架管理员拿牛奶管理员就从自己负责的货架上取货他不管你怎么进来的、买了多少只负责 “存取货” 这个动作。4. 存储层 超市仓库作用货架上的货最终都来自仓库仓库就是数据的最终存放地磁盘文件。货架管理员需要货了就去仓库取卖不完的货再放回仓库存起来。通俗举例仓库里整箱的牛奶、成捆的面包就是最原始的 “数据”货架只是临时展示用的真正的存货都在仓库里。二、存储引擎简介存储引擎就是存储数据建立索引、更新、查询数据等技术的实现方式。存储引擎是基于表的而不得基于库的所以存储引擎也可被称为表类型。在创建表时指定存储引擎show engines; //查看当前数据库支持的存储引擎 -- 建一个电商订单表用 InnoDB支持事务 CREATE TABLE orders ( id INT PRIMARY KEY, user_id INT, money DECIMAL(10,2) ) ENGINEInnoDB; //默认就是这个所以可以不写 -- 建一个博客文章表用 MyISAM只读快 CREATE TABLE articles ( id INT PRIMARY KEY, title VARCHAR(200), content TEXT ) ENGINEMyISAM;三、存储引擎的特点1. InnoDB“全能管家”MySQL 5.5 及以上默认性格稳重靠谱、安全第一啥活都能干尤其擅长复杂业务。核心技能支持 “事务”比如转账时扣钱和加钱要么一起成要么一起失败不会出问题支持 “行级锁”多人同时改不同数据不冲突比如电商平台多人下单不卡支持 “外键(foreign key)”比如订单表必须关联用户表不会出现 “没有用户的订单”崩溃恢复服务器断电也不怕重启后数据能恢复。适用场景绝大多数业务系统电商、支付、管理系统等只要涉及数据安全和并发操作选它准没错2. MyISAM“快手管家”老版本默认现在少用性格干活快、不墨迹但有点 “不靠谱”只适合简单活。核心技能读写速度比 InnoDB 快因为不做事务、锁这些 “额外工作”占用磁盘空间小数据存储更紧凑。缺点不支持事务、外键只支持 “表级锁”多人同时改一张表会排队并发差崩溃后数据可能丢失没有恢复机制。适用场景静态数据、只读场景比如博客文章、新闻列表、日志归档只查不改或很少改3. Memory“临时管家”内存型引擎性格速度飞起来但健忘重启就忘。核心技能数据全存在内存里查询、修改速度极快比磁盘快几百倍。缺点服务器重启 / 断电数据直接消失不支持事务数据量不能太大受内存大小限制。适用场景临时计算、缓存数据比如临时统计报表、会话缓存用完就扔的那种。四、存储引擎的选择场景描述选哪个引擎电商下单、支付、用户管理要安全、要并发InnoDB必选博客文章、新闻列表只看不改要快MyISAM临时统计数据、会话缓存用完就扔要极速Memory索引是帮助 MySQL 高效获取数据 的 数据结构 (有序)索引其实就是数据库表的 “字典目录”—— 就像查字典不用从头翻到尾先看目录找页码再翻页数据库查数据也不用扫描全表靠索引直接定位到要找的行速度能快几十上百倍。比如查 “id100 的用户”有索引 1 毫秒就能找到没索引可能要翻几万行数据。索引的核心作用就 2 个加速查询这是最核心的比如查询SELECT * FROM user WHERE id100有索引的话1 毫秒就能找到没索引的话可能要扫描几万行数据慢几十倍。优化排序比如查询SELECT * FROM user ORDER BY name有name字段的索引MySQL 直接用索引的有序结构排序不用额外做 “排序操作”效率更高。索引分类聚集索引索引 数据查一次就到位速度最快默认主键就是二级索引索引 主键查两次才拿到完整数据速度比聚集索引慢一点先查到主键再去聚集索引查但灵活可以给多个字段加。索引语法create [unique|fulltext]index index_name on table_name (index_Tname,); //创建索引 show index from table_name; //查看索引 drop index index_name on table_name; //删除索引主键索引PRIMARY KEY“唯一的目录页”特点每个表只能有 1 个字段值必须唯一不能重复且不能为NULL比如user表的id字段。通俗理解字典的 “唯一页码”每个页码对应唯一的词条绝对不会重复。建表时直接指定CREATE TABLE user ( id INT PRIMARY KEY, -- 主键索引自动创建 name VARCHAR(50) );常规索引INDEX“普通目录页”特点可以有多个字段值可以重复、可以为NULL比如user表的name、phone字段。通俗理解字典的 “拼音目录”多个词条可能拼音相同比如 “李” 和 “理”可以重复。建表后添加-- 给 name 字段加普通索引 CREATE INDEX idx_user_name ON user(name);3. 唯一索引UNIQUE“不重复的普通目录”特点可以有多个但字段值必须唯一不能重复可以为NULL比如user表的phone字段手机号不能重复。通俗理解字典的 “身份证号目录”每个身份证号对应唯一的人不能重复但可以有空缺比如有人没提供。用法-- 给 phone 字段加唯一索引防止重复手机号 CREATE UNIQUE INDEX idx_user_phone ON user(phone);五、InnoDB 的索引核心B 树结构InnoDB 用的是B 树做索引就像一棵 “倒过来的树”特点是叶子节点最底层存的是实际数据或数据地址查询时只需要遍历到叶子节点效率稳定所有数据都在叶子节点且叶子节点之间是 “链表” 结构双向链表方便范围查询比如WHERE id BETWEEN 100 AND 200。简单说这种结构让查询 “又快又稳”不管查哪个数据都要走差不多的步骤不会出现 “有时候快有时候慢” 的情况。索引怎么用建表时给主键id加主键索引自动加不用手动给经常查询、排序的字段加普通索引给需要唯一约束的字段手机号、邮箱加唯一索引别乱加索引够用就行日常开发中只要记住 “索引 字典目录”就知道什么时候该加、什么时候不该加啦SQL性能分析show global status like com_______; //查看当前数据库增删改查的访问次数慢查询日志慢查询日志就是 MySQL 的 “慢动作记录仪”—— 专门盯着所有执行的 SQL 语句只要某条 SQL 执行时间超过你设定的 “阈值”默认是 10 秒实际开发中一般设 1~3 秒就把这条 SQL 的 “作案细节”执行时间、执行用户、执行时间点、SQL 语句本身记下来方便你后续排查 “谁拖慢了数据库”。举个例子你做电商网站用户反映 “下单要等 5 秒”打开慢查询日志一看发现SELECT * FROM order WHERE user_id123这条 SQL 执行了 4.8 秒超过了你设的 3 秒阈值日志里还记着它没走索引、扫描了 10 万行数据 —— 这就找到 “罪魁祸首” 了接下来只要给user_id加个索引就能提速。核心用法就 3 个关键点通俗说先 “打开记录仪”开启慢查询日志功能默认是关的需要手动开设 “触发条件”比如设定 “执行超过 2 秒的 SQL 就记录”看 “记录报告”从日志文件里找慢 SQL针对性优化比如加索引、简化 SQL。简单总结慢查询日志就是帮你抓 “拖后腿的 SQL” 的工具有了它不用瞎猜哪条 SQL 慢直接看日志就知道该优化啥profile详细Profile 就是 MySQL 里给 SQL 做 “精准计时” 的工具 —— 像给 SQL 装了个秒表把它执行的每一步比如解析语法、查索引、读数据、排序都拆开来告诉你每步花了多少时间精准找到 “慢在哪”比慢查询日志更细。核心用法查询profile select have_profiling; //查询当前是否有profile操作开开关SET profiling ON/1;临时生效关了终端就没了跑 SQL执行你要分析的语句比如SELECT * FROM order WHERE user_id123;看结果先看所有记录的 SQLSHOW PROFILES;拿到要分析的 SQL 编号比如 Query_ID1再看详细步骤耗时SHOW PROFILE FOR QUERY 1;把 1 换成你的 Query_ID关键看什么结果里会列一堆步骤重点盯耗时最长的比如 “Retrieving Data”读数据久→索引没建好加索引“Sorting Result”排序久→排序字段没加索引“Copying to tmp table”临时表久→分组 / 连接逻辑要优化。慢查询日志告诉你 “哪条 SQL 慢”Profile 告诉你 “这条 SQL 慢在哪个步骤”优化时精准下手不用瞎改explain执行计划EXPLAIN 就是 MySQL 的“SQL 执行计划预览器”—— 不用真的执行 SQL就能提前看到 MySQL 会怎么执行这条 SQL比如走不走索引、扫描多少行数据、用什么连接方式帮你预判 SQL 有没有效率问题从源头避免慢查询。核心用法在你要分析的 SQL 前面加EXPLAIN就行比如-- 原SQL查询用户订单 SELECT * FROM order WHERE user_id123 ORDER BY create_time; ​ -- 加EXPLAIN查看执行计划 EXPLAIN SELECT * FROM order WHERE user_id123 ORDER BY create_time;执行后会返回一张 “执行计划表”不用看复杂字段盯 3 个核心信息就够了重点看 3 列列名通俗含义好情况坏情况typeMySQL 查找数据的 “方式”效率从高到低出现ref或range走索引出现ALL全表扫描没走索引key实际用到的索引名称显示你建的索引比如idx_user_id显示NULL没用到任何索引rowsMySQL 预估要扫描的行数数字越小越好比如几十、几百数字极大比如几万、几十万扫全表例子 1好的执行计划typerefkeyidx_user_idrows50→ 解读MySQL 走了user_id的索引只需要扫 50 行就能找到数据效率高例子 2坏的执行计划typeALLkeyNULLrows100000→ 解读MySQL 没走任何索引要扫描 10 万行数据全表扫肯定慢优化方向给user_id加索引。如果 Extra 列出现Using filesort文件排序或Using temporary临时表说明 SQL 里的ORDER BY或GROUP BY没用到索引需要给排序 / 分组字段加索引比如给create_time加索引就能消除这两个提示。一句话总结EXPLAIN 是 “SQL 体检工具”—— 写好 SQL 后先跑一遍 EXPLAIN只要type不是 ALL、key不为 NULL、rows不大这条 SQL 基本就高效反之就针对性加索引、改查询条件不用等上线才发现慢