一个不懂技术的人如何做网站网站开发的基本原则

一个不懂技术的人如何做网站,网站开发的基本原则,wordpress utc时间差12个小时,网站标题字体1.mysql mvcc 机制 在 MySQL 面试中#xff0c;MVCC#xff08;Multi-Version Concurrency Control#xff0c;多版本并发控制#xff09;是一个高频考点#xff0c;主要考察候选人对事务隔离级别和并发控制机制的理解。以下是针对 MVCC 的核心知识点总结#xff1a;1. m…1.mysql mvcc 机制在 MySQL 面试中MVCCMulti-Version Concurrency Control多版本并发控制是一个高频考点主要考察候选人对事务隔离级别和并发控制机制的理解。以下是针对 MVCC 的核心知识点总结1. mysql MVCC 是什么定义MVCC 是一种通过维护数据的多个版本来实现并发控制的技术目的是在高并发场景下减少锁的竞争提高读操作的性能。解决的问题避免读写操作互相阻塞读不阻塞写写不阻塞读。实现事务的隔离性如REPEATABLE READ和READ COMMITTED隔离级别。2. MVCC 的实现原理核心机制隐藏字段DB_TRX_ID记录最后一次修改该数据的事务 ID。DB_ROLL_PTR指向 Undo Log 中旧版本数据的指针形成数据的版本链。DB_ROW_ID隐含的自增行 ID如果表没有主键。Undo Log存储数据的历史版本用于事务回滚和 MVCC 的版本链访问。每次更新操作会生成一个 Undo Log 记录并通过DB_ROLL_PTR连接成链表。Read View读视图事务在快照读普通SELECT时生成的“数据可见性”快照。包含以下关键信息trx_ids当前活跃未提交的事务 ID 列表。min_trx_id最小活跃事务 ID。max_trx_id下一个即将分配的事务 ID。creator_trx_id创建该 Read View 的事务 ID。3. 数据可见性规则通过Read View判断某行数据的某个版本是否对当前事务可见如果数据版本的DB_TRX_ID min_trx_id说明该版本在 Read View 创建前已提交可见。如果DB_TRX_ID max_trx_id说明该版本在 Read View 创建后生成不可见。如果min_trx_id ≤ DB_TRX_ID ≤ max_trx_id若DB_TRX_ID在trx_ids列表中说明事务未提交不可见。若不在列表中说明事务已提交可见。若当前事务自身修改的数据DB_TRX_ID creator_trx_id可见。如果不可见则通过DB_ROLL_PTR查找 Undo Log 中的旧版本重复上述判断。4. 不同隔离级别的实现READ COMMITTED读已提交每次执行SELECT时生成新的 Read View能看到其他事务已提交的修改。REPEATABLE READ可重复读仅在第一次SELECT时生成 Read View后续读取沿用该视图保证多次读取的一致性。通过 MVCC 间隙锁Next-Key Locks解决幻读问题。4.1 进一步解释首先我们来看一下标准的SQL隔离级别和它们解决的问题脏读Dirty Read一个事务读取了另一个未提交事务修改的数据。不可重复读Non-repeatable Read一个事务内多次读取同一数据但在读取过程中另一个事务修改并提交了数据导致第一个事务两次读取的数据不一致。幻读Phantom Read一个事务在多次查询过程中由于其他事务插入或删除了数据导致每次查询的结果集不同。不同隔离级别对上述问题的解决情况READ UNCOMMITTED: 可能发生脏读、不可重复读和幻读。READ COMMITTED: 防止脏读但可能发生不可重复读和幻读。REPEATABLE READ: 防止脏读和不可重复读但可能发生幻读但在MySQL的InnoDB引擎中通过多版本并发控制MVCC和间隙锁在REPEATABLE READ级别下也可以防止幻读。SERIALIZABLE: 防止所有问题但并发性能最低因为它通过强制事务串行执行来实现。5. 面试常见问题Q1MVCC 如何避免脏读、不可重复读脏读Read View 过滤未提交的事务版本。不可重复读在REPEATABLE READ下Read View 在事务期间保持不变确保多次读取一致性。Q2MVCC 能完全解决幻读吗快照读普通 SELECT通过 MVCC 避免幻读。当前读如SELECT FOR UPDATE可能发生幻读需依赖间隙锁Next-Key Locks解决。Q3Undo Log 何时删除当没有事务需要访问旧版本数据时即所有 Read View 都不再依赖该 Undo Log由后台线程清理。5.1 数据库三范式5.2 mysql 数据库 explain更准确的排序和理解如下访问类型性能详细说明system最优表中只有一行数据等于系统表是const的特例。const极优通过主键或唯一索引的一次扫描最多只返回一条记录。速度快如常量。eq_ref极优在联表查询时使用主键或唯一索引进行关联。对于来自前表的每一行从本表中只读取一行。ref优使用普通索引非唯一进行查找可能返回多条匹配的行。fulltext特殊使用全文索引。性能高度依赖于匹配的相关度和数据量很难简单排序。通常用于文本搜索和常规查询可比性不强。ref_or_null良类似ref但附加了对 NULL 值的搜索。unique_subquery优在子查询中将IN查询转换为高效的EXISTS子查询使用主键。index_subquery良类似unique_subquery但使用的是普通索引。range中使用索引检索给定范围的行如BETWEEN,,IN。关键是不再是全索引扫描。index_merge不稳定这是原列表中最需要调整的地方。它表示使用了索引合并优化使用多个索引。它的性能可能很好也可能很差取决于合并哪些索引以及需要扫描的数据量。有时它甚至不如单个范围的range扫描。不应简单地认为它比range好。index差全索引扫描。虽然不读数据行只读索引但如果索引很大速度依然很慢。ALL最差全表扫描。没有使用索引性能最差必须优化。例如从基本使⽤使⽤的⾓度来讲主键索引: InnoDB 主键是默认的索引数据列不允许重复不允许为 NULL⼀个表只能有⼀个主键。唯⼀索引: 数据列不允许重复允许为 NULL 值⼀个表允许多个列创建唯⼀索引。普通索引: 基本的索引类型没有唯⼀性的限制允许为 NULL 值。组合索引多列值组成⼀个索引⽤于组合搜索效率⼤于索引合并。5.3 索引下推它的核心思想是将一部分数据过滤工作从MySQL服务器层“下推”到存储引擎层去执行。没有索引下推时是如何工作的 让我们通过一个例子来理解。假设我们有一张 users 表和一个索引 INDEX (name, age) sql CREATE TABLE users ( id INT PRIMARY KEY, name VARCHAR(50), age INT, city VARCHAR(50), KEY idx_name_age (name, age) ); 执行以下查询 sql SELECT * FROM users WHERE name LIKE 张% AND age 20; 存储引擎 使用联合索引 idx_name_age找到所有 name 以 “张” 开头的记录。 因为索引中包含 name 和 age 字段但它只根据 name 这一部分来定位数据页。 将所有这些匹配 name LIKE 张% 的完整数据行即使是使用索引也需要回表读取完整行数据返回给MySQL的服务器层。 服务器层 接收到存储引擎返回的所有 name LIKE 张% 的行。 然后由服务器层来执行第二条条件 age 20 的过滤。 问题所在存储引擎返回了大量 name 符合条件但 age 不等于20的行这些不必要的行在服务器层被过滤掉了导致了额外的I/O和网络传输在服务器层和存储引擎层之间。 开启索引下推后是如何工作的 同样是这个查询和索引 INDEX (name, age) 存储引擎 同样使用索引 idx_name_age找到所有 name 以 “张” 开头的记录。 关键区别来了由于 age 字段也在同一个索引中存储引擎会就地检查这些索引记录中的 age 字段是否等于20。 只有同时满足 name LIKE 张% 和 age 20 的索引项存储引擎才会去回表读取完整的行数据然后返回给服务器层。 服务器层 接收到的行已经是完全符合 name LIKE 张% AND age 20 的结果集了。 服务器层直接使用这些数据无需再做额外的过滤。5.4 mysql 优先级顺序优先级顺序表优先级运算符描述1()括号强制改变优先级2-~!一元运算符负号、正号、位非、逻辑非3^位异或4*/%DIV乘、除、取模、整除5-加、减6位左移、位右移7位与8位或9!LIKEREGEXPINISBETWEENCASE比较运算符10NOT逻辑非11AND逻辑与12XOR逻辑异或13OR14:赋值运算符重要说明括号最高优先级sql-- 括号强制改变运算顺序 SELECT (1 2) * 3; -- 结果为 9 SELECT 1 2 * 3; -- 结果为 7算术运算符优先级sql-- 先乘除后加减 SELECT 2 3 * 4; -- 14不是 20 SELECT 10 / 2 3; -- 8不是 2 SELECT 10 % 3 * 2; -- 2不是 10%64逻辑运算符优先级sql-- AND 优先级高于 OR SELECT * FROM users WHERE age 18 OR status active AND deleted 0; -- 等价于age 18 OR (status active AND deleted 0) -- 使用括号明确意图 SELECT * FROM users WHERE (age 18 OR status active) AND deleted 0;比较运算符优先级sql-- 比较运算符优先级低于算术运算符 SELECT * FROM products WHERE price * 1.1 100; -- 先计算 price*1.1再比较特殊注意事项BETWEEN的优先级sql-- BETWEEN 优先级较低 SELECT * FROM table WHERE id 1 OR id BETWEEN 5 AND 10; -- 等价于id 1 OR (id 5 AND id 10)IN运算符sql-- IN 优先级高于 OR SELECT * FROM users WHERE status active OR id IN (1, 2, 3); -- 等价于status active OR (id IN (1, 2, 3))IS NULL运算符sql-- IS NULL 优先级 SELECT * FROM users WHERE name IS NULL OR name ;5.6 集群架构设计6. 总结优点提高并发性能读写互不阻塞。缺点需要维护多版本数据增加存储和 CPU 开销。适用场景读多写少的高并发系统如电商、社交应用。掌握 MVCC 的核心机制和与隔离级别的关系能帮助你在面试中清晰阐述其工作原理和应用场景。MySQL 数据库的备份方式多样根据业务需求、数据量、停机时间容忍度等因素可选择合适的备份策略。以下是常见的备份方式及其特点2.mysql 备份一、逻辑备份1. mysqldump原理生成 SQL 语句文件CREATE TABLE INSERT 语句。优点跨版本兼容如从 MySQL 5.7 迁移到 8.0。可选择性备份表或数据库。支持压缩输出--compress。缺点大数据量时备份和恢复较慢。备份时可能锁表默认使用--lock-tables。命令示例bash复制mysqldump -u [user] -p [database] backup.sql2. mysqlpumpMySQL 5.7原理类似mysqldump但支持并行导出。优点多线程加速导出--default-parallelismN。支持压缩--compress-output。缺点不保证数据一致性需配合事务或 FTWRL 锁。部分功能限制如无法导出事件。3. SELECT … INTO OUTFILE原理将单表数据导出为 CSV/文本文件。优点轻量级导出特定表数据。可与其他工具如 LOAD DATA INFILE结合使用。缺点仅备份数据不备份表结构。需要手动处理锁。二、物理备份1. 直接复制数据文件原理直接拷贝 MySQL 数据目录/var/lib/mysql。优点备份速度快适合大数据库。支持热备份需保证数据一致性。缺点需停机或使用锁FLUSH TABLES WITH READ LOCK。依赖存储引擎如 InnoDB 需同时备份事务日志。2. Percona XtraBackup原理物理备份工具支持 InnoDB 热备份。优点在线备份不锁表。支持增量备份和压缩。快速恢复直接替换数据文件。命令示例bash复制xtrabackup --backup --user[user] --password[pass] --target-dir/backup/三、增量备份1. 基于二进制日志Binlog原理先做全量备份之后定期备份 Binlog 文件。恢复时通过全量备份 Binlog 重放恢复到指定时间点。优点节省存储空间。支持时间点恢复PITR。配置要求启用log_bin和server_id。定期备份 Binlog 并清理过期文件。2. Percona XtraBackup 增量备份原理基于全量备份仅备份自上次备份后修改的数据页。优点减少备份时间和存储占用。支持合并增量备份到全量备份。四、主从复制原理通过主从架构实时同步数据。优点从库可视为实时备份。支持读写分离和故障切换。缺点需额外硬件资源。主从延迟可能导致数据不一致。五、云服务备份AWS RDS/Aurora自动每日备份 Binlog 保留。阿里云/Azure支持手动快照和自动策略。优点自动化管理无需手动维护。集成存储和恢复功能。六、快照备份原理利用存储层快照如 LVM、ZFS、云硬盘快照。优点瞬时完成秒级。适合大规模数据备份。条件需确保快照时数据库处于一致性状态如FLUSH TABLES WITH READ LOCK。七、备份策略建议全量 增量组合每周全量备份 每日增量备份。验证备份定期测试备份文件可恢复性。异地存储备份文件存放到不同地理位置或云存储。加密与压缩保护敏感数据减少存储成本。8 mysql 数据库 目录etc/my.cnf 改了以后需要重启一下服务器七、工具对比与选型建议工具/方案适用场景优点缺点mysqldump小库、单表备份跨版本迁移简单灵活无需额外依赖大库备份慢锁表风险XtraBackup大库热备份生产环境主流方案快速支持增量开源免费需学习配置MySQL ShellMySQL 8.0 环境并行导出高性能集成度高仅限新版 MySQL云服务内置备份云托管数据库自动化无需运维依赖云厂商成本较高在 MySQL 面试中优化参数是高频考点。以下是一些面试中常被问及的优化参数及其核心解释帮助你在面试中快速组织回答3.mysql 内存参数优化1. 内存相关参数innodb_buffer_pool_size作用InnoDB 存储引擎的核心缓存池缓存数据和索引。直接影响读性能。推荐值通常设置为物理内存的50%~80%例如 64G 服务器可设为 40G~50G。面试追问如何确定当前值是否合理通过监控Innodb_buffer_pool_read_requests缓存命中次数和Innodb_buffer_pool_reads直接读磁盘次数计算缓存命中率命中率 1 - (reads / read_requests)理想值应 99%。key_buffer_size作用MyISAM 表的索引缓存如果使用 MyISAM 表。推荐值若主要使用 InnoDB可设为 64M~256M若大量使用 MyISAM需根据索引大小调整。2. 连接与线程参数max_connections作用MySQL 允许的最大并发连接数。推荐值默认 151通常调整为500~2000需结合业务和Threads_connected监控。面试追问连接数过多会导致什么问题内存溢出每个连接占用独立内存、CPU 上下文切换开销大。thread_cache_size作用缓存空闲线程避免频繁创建和销毁线程。推荐值根据Threads_created状态调整通常设为64~128。3. 事务与日志参数innodb_flush_log_at_trx_commit作用控制事务日志Redo Log的刷盘策略平衡性能与数据安全。推荐值1默认每次事务提交都刷盘保证 ACID性能最低。0或2每秒刷盘性能高但可能丢失最近 1 秒的事务用于非关键业务或从库。面试追问与sync_binlog的区别sync_binlog控制二进制日志Binlog的刷盘策略两者共同影响数据一致性和性能。sync_binlog作用控制 Binlog 的刷盘频率。推荐值1默认每次事务提交刷盘保证主从数据一致性。0由操作系统决定刷盘时机性能高但可能丢失数据。4. 查询优化参数tmp_table_size和max_heap_table_size作用控制内存临时表的最大大小。若临时表超过此值会转为磁盘临时表性能下降。推荐值通常设为64M~256M需结合业务中复杂查询的临时表大小调整。sort_buffer_size和join_buffer_size作用排序和连接操作的内存缓冲区。推荐值默认值256KB~2MB通常足够避免全局设置过大每个连接独立分配。5. InnoDB 存储引擎参数innodb_log_file_size作用Redo Log 文件大小影响事务提交速度和崩溃恢复时间。推荐值通常设为1~4G需保证 Redo Log 总大小innodb_log_file_size * innodb_log_files_in_group足够容纳 1~2 小时的写入量。innodb_io_capacity作用InnoDB 后台线程如刷脏页的 IO 吞吐能力。推荐值HDD200~500SSD2000~40006. 其他高频参数table_open_cache作用缓存已打开表的句柄数量减少频繁打开表的开销。推荐值根据Opened_tables状态调整通常设为1024~4096。query_cache_type和query_cache_size注意MySQL 8.0 已移除查询缓存作用缓存查询结果适用于读多写少的场景。问题高并发写入场景下查询缓存会因频繁失效导致性能下降通常建议关闭。