A. 什么是数据库系统的事务
实 时 事 务 模 型
----1 ． 系 统 模 型与 传 统 数 据 库 系 统 相 类 似， 实 时 数 据 库 系 统 的 操 作 也 是 以 事 务 的 形 式 出 现。 事 务 就 是 包 含 在BEGIN/COMMIT/ABORT 之 间 的 操 作 序 列。 系 统 以 事 务 为 单 位 分 配CPU、 数 据 等 资 源， 进 行 优 先 级 的 分 配、 调 度 处 理 等。
---- 实 时 数 据 库 系 统 中 的 事 务 与 传 统 事 务 有 很 大 的 不 同， 其 事 务 可 以 有 定 时 限 制（ 典 型 地 为 截 止 期）， 系 统 追 求 的 目 标 不 是 系 统 的 吞 吐 量， 而 是 单 个 事 务 定 时 限 制 的 满 足， 以 使 满 足 定 时 限 制 的 事 务 比 率 最 大； 传 统 事 务 的 原 子 性、 一 致 性、 隔 离 性 及 永 久 性 在 实 时 环 境 下 变 得 太 严 格 或 不 可 能； 要 求 采 用" 识 时" 机 制 来 处 理 事 务 的 调 度 或 并 发 控 制， 而 不 是 传 统 的 先 来 先 服 务 方 式。
----2 ． 结 构 模 型
---- 传 统 数 据 库 中 事 务 就 是 一 个 平 坦 的 操 作 序 列， 事 务 的 执 行 要 么 顺 利 执 行 到 提 交， 要 么 夭 折 而 不 在 系 统 的 任 何 部 分 留 有 痕 迹。 在 实 时 应 用 环 境 下 则 不 同：
应 用 语 义 有 时 显 式 地 要 求 结 构 上 的 一 个 事 务 为 另 一 个 事 务 的 子 事 务。 例 如， 在CAD 工 程 中， 一 个 工 程 事 务 划 分 成 若 干 个 设 计 事 务， 而 每 一 设 计 事 务 又 可 分 成 若 干 个 子 任 务 而 分 配 给 各 设 计 者。
实 时 应 用 中 被 触 发 的 活 动 依 应 用 要 求 可 以 是 触 发 它 的 事 务 的 子 事 务。 在 过 程 控 制、 自 动 化 等 领 域 这 种 情 形 很 普 遍。
在 分 布 式 应 用 环 境 中， 一 个 事 务 可 能 要 分 出 若 干 在 不 同 节 点 上 执 行 的 代 理 事 务， 它 们 分 工 合 作 且 都 作 为 原 事 务 的 子 事 务。
在 工 程 应 用 中， 普 遍 存 在 长 寿 事 务 或 开 端 事 务。 这 种 事 务 会 造 成 系 统 资 源 需 求 的 瓶 颈。 为 此， 可 将 这 种 事 务 划 分 成 若 干 逻 辑 相 对 独 立 的 子 事 务， 以 便 当 其 结 束 时 能 提 前 释 放 占 用 的 资 源。
---- 所 以， 实 时 应 用 要 求 系 统 提 供 事 务 嵌 套 机 制。 包 含 其 他 事 务 的 事 务 称 为" 父 事 务"， 被 包 含 的 事 务 称 为 " 子 事 务"， 没 有 父 事 务 的 事 务 为" 根 事 务"。 事 务 之 间 可 以 形 成 嵌 套 关 系。
实 时 事 务 的 特 征
----1 ． 定 时 性
---- 实 时 应 用 中 事 务 的 定 时 性 来 源 于 两 方 面： 一 是 外 部 环 境 显 式 给 出 的 反 应 时 间 要 求， 如 截 止 期 等； 二 是 由 于 系 统 中 的 数 据 随 时 间 变 化 而 转 嫁 来 的。
---- 定 时 性 包 括 了 两 方 面 的 含 义：
---- 定 时 限 制 事 务 的 执 行 具 有 显 式 的 时 限， 如 期 限、 截 止 时 间 等。 这 是 由 于 控 制 系 统 要 随 时 紧 紧 地 跟 踪 被 控 系 统 而 引 起 的， 它 要 求RTDB 必 须 有 时 间 处 理 机 构。 时 限 还 可 有 软 硬 之 分。
---- 定 时 正 确 性 事 务 能 按 合 适 的 时 间 要 求 正 确 执 行。 这 是 由 于 要 求 数 据 对 于 控 制 系 统 的 各 种 决 策 活 动 随 时 有 效 而 引 起 的， 它 要 求 权 衡 定 时 限 制 与 数 据 一 致 性 等 多 方 面 因 素， 提 供 合 适 的 调 度 算 法。
---- 实 时 事 务 有 不 同 的 定 时 限 制， 其 中 最 重 要 的 有：
---- 截 止 时 间 实 时 事 务 完 成 的 最 后 期 限。 它 可 以 有 硬、 软 之 分， 具 有 硬 截 止 时 间 的 事 务（ 称 为 硬 实 时 事 务）， 必 须 在 其 截 止 时 间 以 前 完 成， 否 则 将 带 来 灾 难 性 的 后 果， 故 到 达 其 截 止 时 间 还 不 能 完 成 的 硬 实 时 事 务 必 须 夭 折。 具 有 软 截 止 时 间 的 事 务（ 称 为 软 实 时 事 务）， 应 该 在 其 截 止 期 完 成， 但 超 过 其 截 止 时 间 也 还 有 一 定 意 义（ 尽 管 不 断 下 降）， 故 软 实 时 事 务 到 达 其 截 止 时 间 后 不 必 立 即 夭 折 它。
---- 到 达 时 间 事 务 在 系 统 中 生 成 的 时 间。 它 可 以 是 可 预 报 的， 也 可 以 是 不 可 预 报 的。 可 预 报 的 到 达 时 间 可 显 式 地 给 出 或 者 作 为 一 个 导 出 函 数， 如 周 期 事 务 的 到 达 时 间 是 可 预 报 的。 不 可 预 报 的 到 达 时 间 是 指 当 相 应 事 务 到 达 系 统 时 才 能 知 道， 非 周 期 事 务 的 到 达 时 间 就 是 不 可 预 报 的。
---- 期 望 执 行 时 间 估 算 的 最 坏 情 况 执 行 时 间。 由 于 各 种 不 可 预 报 性 因 素， 它 很 难 做 到 准 确， 估 算 的 最 坏 情 况 执 行 时 间 可 能 与 实 际 情 况 相 差 很 大。 然 而， 为 了 合 理 地 得 到 事 务 的 截 止 时 间 及 适 当 地 调 度 以 使 其 满 足， 又 必 须 事 先 较 准 确 地 估 算 其 执 行 时 间。
----2 ． 语 义 相 关 性
---- 实 时 数 据 库 事 务 之 间 存 在 着 各 种 关 系， 包 括 结 构 关 系、 数 据 与 通 信 关 系、 时 间 关 系 等， 这 些 关 系 带 来 了 事 务 间 的 各 种 相 关 性。
----(1) 结 构 相 关
---- 它 来 自 于 复 杂 事 务 模 型 的 结 构 特 征， 用 来 建 模 复 杂 事 务 内 部 并 发 事 务 行 为 的 一 种 约 束。 不 同 的 复 杂 事 务 模 型 有 不 同 的 结 构 相 关 性， 但 它 们 可 以 通 过 事 务 间 的" 执 行 依 赖 性" 来 定 义， 实 时 嵌 套 事 务 中 基 本 的 事 务 依 赖 有：
子 事 务 对 父 事 务 的 开 始 依 赖（BD）： 子 事 务 开 始 前 父 事 务 已 经 开 始；
父 事 务 对 子 事 务 的 提 交 依 赖(CD）： 父 事 务 提 交 前 子 事 务 已 经 结 束（ 提 交 或 夭 折）；
子 事 务 对 父 事 务 的 夭 折 依 赖（AD）： 父 事 务 夭 折 则 子 事 务 一 定 夭 折。
----(2) 数 据 相 关
---- 数 据 相 关 就 是 不 同 事 务 间 的 共 享 数 据 联 系， 但 此" 共 享" 概 念 比 传 统 的 具 有 更 广 的 意 义： 实 时 嵌 套 事 务 中 的 子 事 务 共 享 父 事 务 数 据， 子 事 务 提 交 时 其 对 数 据 库 的 更 改 委 托 给 父 事 务， 只 有 父 事 务 提 交 时 才 能 真 正 地 写 入 数 据 库。
----(3) 功 能 替 代/ 结 果 补 偿
---- 一 个 实 时 应 用 常 常 由 若 干 任 务 组 成， 而 一 个 任 务 有 时 可 以 通 过 不 同 途 径 来 实 现。 一 个 应 用 建 模 为 一 个 事 务， 一 个 任 务 则 建 模 为 一 组 功 能 等 价 的 子 事 务， 称 为 该 任 务 的 替 代 集。 若 一 个 任 务 的 替 代 集 中 的 子 事 务 之 一 能 成 功 执 行， 则 该 任 务 是 可 完 成 的。 若 对 应 一 个 事 务 的 所 有 任 务 可 完 成， 则 该 事 务 是 成 功 的（ 可 提 交）。 功 能 替 代 导 致 了 事 务 执 行 路 径 的 不 确 定 性， 即 一 个 事 务 成 功 执 行 的 路 径 依 赖 于 执 行 过 程 中（ 子 事 务） 失 败 的 发 生， 且 即 使 某 些 子 事 务 失 败 了， 事 务 仍 可 能 顺 利 提 交。 这 还 体 现 了 实 时 事 务 的 健 壮 性， 即 有 的 事 务（ 任 务） 不 能 失 败。
---- 由 于 前 面 所 述 的 事 务 的 结 构 复 杂 性 和 功 能 替 代 性， 因 此， 事 务 的 执 行 经 历 不 确 定， 一 个 子 事 务 的 执 行 直 到 提 交 时 还 不 能 确 定 它 是 否 需 要。 若 一 个（ 子） 事 务 提 交 后， 发 现 它 是 不 需 要 的， 该 怎 么 办 ？ 另 一 方 面， 一 个 实 时 事 务 可 以 物 理 改 变 现 实 世 界 的 状 态， 换 句 话 说， 事 务 可 以 启 动 各 种 活 动， 这 些 活 动 在 它 提 交 前 就 已 经 影 响 了 现 实 世 界， 因 而 当 这 种 事 务 夭 折 时， 不 能 进 行 传 统 意 义 下 的" 还 原"（Undo）。 于 是 需 要 一 种" 补 偿" 活 动 来 抵 消 它 所 有 的 影 响， 这 种 补 偿 活 动 也 是 事 务。 对 于 一 个（ 子） 事 务， 若 存 在 能 抵 消 它 提 交 后 所 产 生 的 所 有 影 响 的（ 子） 事 务， 则 称 其 为 是 可 补 偿 的， 否 则 是 不 可 补 偿 的。 当 然， 不 是 每 一 个（ 子） 事 务 都 是 可 补 偿 的， 不 可 补 偿 的（ 子） 事 务 在 知 道 它 确 实 是 需 要 的 以 前， 一 定 不 能 提 交。
实 时 事 务 分 类
---- 实 时 事 务 可 以 从 不 同 的 侧 面 进 行 分 类。
----1 ． 按 关 键 性 分 类
---- 也 就 是 按 事 务 时 限（ 截 止 期） 的 性 质， 即 事 务 超 截 止 期 对 系 统 带 来 的 影 响 分 类。 而 这 种 时 限 的 性 质 可 以 很 好 地 用 价 值 函 数 来 建 模， 于 是 我 们 有：
---- 硬（ 截 止 期/ 实 时） 事 务 超 截 止 期 会 导 致 恶 果（ 价 值 函 数 取 大 且 可 能 不 断 增 加 的 负 值）。 它 对 应 于 安 全 危 急 性 活 动。
---- 软（ 截 止 期/ 实 时） 事 务 超 截 止 期 仍 有 一 定 的 价 值， 且 价 值 不 断 下 降， 直 到 某 一 时 刻（ 称 为 最 终 有 效 时 间） 降 到 零， 此 后 保 持 为 零（ 不 会 为 负）。
---- 固（ 截 止 期/ 实 时） 事 务 一 旦 到 达 截 止 时 间， 其 价 值 立 即 降 为 零， 此 后 固 定 为 零（ 也 不 会 为 负）。 显 然， 它 是 软 实 时 事 务 在 最 终 有 效 时 间 与 截 止 时 间 重 合 情 况 的 特 例。
----2 ． 按 功 能 分 类
---- 一 个 实 时 数 据 库 系 统 以 两 种 方 式 直 接 与 现 实 世 界 交 互 作 用， 一 是 关 于 现 实 世 界 状 态 或 事 件 的 信 息 被 记 录 到 数 据 库 中， 二 是 事 务 可 以 启 动 各 种 影 响 现 实 世 界 的 活 动。 这 就 给 予 我 们 一 种 如 下 事 务 分 类：
---- 数 据 接 收 事 务 记 录 现 实 世 界 的 状 态 或 发 生 的 事 件 到 数 据 库 中。 它 是 简 单 的 只 写 事 务； 为 了 保 持 数 据 库 的" 外 部 一 致" 和 跟 踪 记 录， 它 应 是 短 的、 周 期 的， 且 应 是 被 立 即 执 行（ 不 能 等 待 和 阻 塞） 的 硬 实 时 事 务。 为 了 保 证 其 定 时 限 制 的 满 足， 它 可 能 会 引 起 对 数 据 库 一 致 性 的 破 坏。
---- 数 据 处 理 事 务 类 似 传 统 数 据 库 的 事 务。 它 用 来 恢 复 已 违 反 了 一 致 性（ 可 能 由 于 数 据 接 收 事 务 的 结 果） 的 数 据 库 的 状 态。 这 种 事 务 可 看 作 维 护 正 常 运 行 的 监 控 器， 它 可 能 是" 长 寿" 的。
---- 控 制 事 务 引 起 现 实 世 界 中 有 关 活 动 的 执 行。 像 数 据 接 收 事 务 一 样， 这 种 事 务 是 很 短 的， 尽 管 所 引 起 的 现 实 活 动 可 能 要 执 行 很 长 时 间。 它 通 常 也 是 硬 实 时 的。 这 种 事 务 还 可 以 作 为 数 据 处 理 事 务 的 子 事 务 而 被 调 用， 而 它 本 身 也 可 以 触 发 子 事 务， 比 如 以 一 子 事 务 来 检 测 所 引 起 的 现 实 活 动。
实 时 事 务 的 正 确 性
----1 ． 正 确 性 概 念 及 内 涵 实 时 事 务 与 传 统 事 务 的 本 质 区 别 就 在 于 其 有 定 时 限 制， 因 此， 事 务 处 理 必 须 同 时 满 足 一 致 性 要 求 和 定 时 限 制。 虽 然 实 时 事 务 的 正 确 性 与 传 统 事 务 一 样， 也 包 括 数 据 库 状 态 正 确 性 和 事 务 执 行 正 确 性 两 个 方 面， 但 其 含 义 与 内 容 有 很 大 的 不 同。 数 据 库 状 态 正 确 性 包 含 内 部 一 致 和 时 间 一 致， 事 务 执 行 正 确 性 则 包 含 其 结 果 正 确 性、 行 为 正 确 性、 结 构 正 确 性 和 时 间 正 确 性。
----2 ． 正 确 性 标 准
---- 传 统 数 据 库 中 的 原 子 性 和 可 串 行 化 包 含 了 事 务 正 确 性 的 所 有 概 念。 而 实 时 嵌 套 事 务 正 确 性 的 内 容 更 为 丰 富， 实 现 的 手 段 也 就 更 为 复 杂。 传 统 可 串 行 化 标 准 在 实 时 环 境 下 太 严 格 或 不 适 合， 限 制 了 系 统 中 事 务 执 行 的 并 发 度， 对 于 满 足 事 务 定 时 限 制 是 不 利 的。 我 们 开 发 了 一 种 新 颖 的 准 一 致 性 可 串 行 化 并 发 控 制 策 略， 事 务 执 行 给 系 统 带 来 的 不 一 致 被 限 定 在 一 定 的 范 围 内， 并 在 一 定 的 时 机 恢 复 数 据 库 到 一 致 状 态。 而 实 时 事 务 的 时 间 正 确 性 需 要" 识 时" 协 议 实 现， 结 构 正 确 性 需 要 事 务 管 理 检 查 事 务 间 的 结 构 相 关 性 来 实 现。
实 时 事 务 处 理
----1 ． 实 时 事 务 优 先 级 分 配
---- 实 时 事 务 的 调 度 和 并 发 控 制 都 是 基 于 事 务 的 优 先 级 进 行 的， 因 此， 如 何 分 配 事 务 的 优 先 级 是 一 个 重 要 的 问 题。
---- 常 见 的 事 务 优 先 级 分 配 算 法 有 以 下 几 种：
---- 最 早 放 行 最 优 先（Earliest Release First） 该 策 略 将 最 高 优 先 级 指 派 给 具 有 最 早" 放 行"（Release） 时 间 的 事 务。 所 谓 放 行 时 间 就 是 事 务 可 以 开 始 执 行 的 最 早 时 间， 与 此 相 联 的 有 事 务 到 达（Arrive） 时 间、 事 务 接 纳（Admission） 时 间。
---- 截 止 期 最 早 最 优 先（Earliest Deadline First） 即 具 有 最 早 截 止 期 者 优 先 级 最 高。
---- 可 达 截 止 期 最 早 最 优 先（Earliest Feasible Deadline First） 具 有 最 早 的 可 达 截 止 期 者 优 先 级 最 高。 所 谓 一 个 事 务t 的 截 止 期 是 当 前 时 间" 可 达 到" 的， 乃 指 τ ＋（E －P） ≤d。 这 里 τ 为 当 前 时 间，E、P 分 别 为 事 务T 的 执 行 时 间 估 算 和 已 执 行 时 间， d 为 其 截 止 期。
---- 空 余 时 间 最 短 最 优 先（Least Slack First） 事 务t 的 空 余 时 间S=d －（ τ ＋E －P）， 即 推 迟T 的 执 行 而 仍 然 满 足 其 截 止 期 的 可 推 迟 时 间 量 估 算。
---- 价 值 最 高 最 优 先（Highest Value First） 每 一 事 务 都 有 一 价 值 函 数， 其 值 最 大 者 最 优 先。 问 题 是 如 何 合 理 地 构 造 价 值 函 数， 一 个 例 子 是：
---- V（t）=c（w1（ τ － τS） －w2d ＋w3P －w4S）
---- 其 中 τ、d、P、S 的 意 义 同 上，c、 τs 分 别 为 t 的 危 急 度、 开 始 时 间，wi 为 加 权 因 子。
---- 价 值 密 度 最 大 最 优 先（Greatest Value Density First） 价 值 密 度 函 数 为：
---- 即 事 务 完 成 时 的 期 望 价 值 与 实 现 该 价 值 所 需 计 算 量 的 比 最 大 者 优 先 级 最 高。 显 然， 对 于 期 望 价 值 一 样 的 事 务， 该 策 略 偏 向 较 短 者， 因 为 它 每 单 位 消 耗 时 间 所 获 得 的 价 值 更 大。 与 上 面 的HVF 策 略 一 样， 这 里 也 有 如 何 设 计 价 值 函 数 的 问 题。
----2 ． 实 时 事 务 并 发 控 制 和 调 度
---- 在 实 时 应 用 环 境 中， 如 果 处 理 不 当， 可 能 造 成" 优 先 级 颠 倒"， 即 优 先 级 高 的 事 务 等 待 优 先 级 低 的 事 务， 这 对 实 现 事 务 的 定 时 限 制 是 不 利 的。 为 此， 我 们 提 出 了 以 下 几 种 改 进 方 案：
----(1) 优 先 级 继 承
---- 优 先 级 继 承 的 基 本 思 想 是： 当 发 生 优 先 级 颠 倒 时， 将 占 有 者tH 的 优 先 级 提 高 到 与tR 的 一 样（ 即 继 承tR 的 优 先 级），tH 继 续 执 行 直 到 结 束（ 提 交 或 夭 折）。 在tH 因 某 种 原 因（ 如 成 为 死 锁 的 牺 牲 者） 而 重 启 动 时， 它 恢 复 原 来 的 优 先 级。 让tH 继 承 tR 优 先 级 是 为 了 让 它 尽 快 完 成， 因 为tH 的 进 展 也 意 味 着tR 的 进 展。 这 种 策 略 称 为 优 先 继 承（PI）。
----(2) 高 优 先 级 夭 折
---- 这 种 策 略 的 思 想 是， 当 发 生 优 先 级 颠 倒 时， 夭 折 低 优 先 级 的tH 而 让 高 优 先 级 的tR 执 行。 该 策 略 称" 高 优 先" 法（HP）。
---- 这 种 策 略 可 以 消 除 死 锁， 但 它 的 问 题 是：
对 那 些 已 执 行 时 间 很 长 而 还 需 执 行 的 时 间 已 很 短 的tH， 夭 折 的 代 价 很 大。 尤 其 是 当dH（ 截 止 时 间） －ct（ 当 前 时 间） 与tH 的" 剩 余 执 行 时 间 估 算"el(tH) 相 差 不 大 时， 重 启 动 必 然 导 致 其 超 截 止 时 间， 而 且 浪 费 大 量 系 统 资 源， 使 整 个 系 统 性 能 下 降。
若 采 用 像LSF 这 样 的 动 态 优 先 级 分 配 策 略， 则 被 夭 折 而 重 启 动 的tH 可 能 马 上 会 有 比tR 更 高 的 优 先 级。 为 此， 当 重 启 动 的tH 再 次 与 tR 冲 突 时，tR 可 能 又 被tH 夭 折， 这 样 就 导 致 循 环 夭 折。
B. access数据库破解密码问题
不是恶意加密,而是你的数据库应该被你改成ASP的扩展名
被注入者当ASP加入了木马,结果破坏了,这样的数据库表现就是提示需要密码。但实际上文件本身破坏。
这个不好恢复,你可以尝试用二进制编辑工具ultraedit打开,去掉带有病毒代码的部分
以后以后要注意备份,因为安全总是不能打100%保证的。
我自认为对安全很了解的人都不敢说能保证绝对安全的，而备份无疑是后悔药。
修改之前记得备份原来的文件，防止出现越改越乱的情况
还有一个建议就是数据库不要改扩展名ASP，相反使用MDB的扩展名反而安全。
因为ASP的扩展名是能执行的，可以通过留言等途径提交ASP的代码，然后访问该数据库文件，来运行。
防止下载数据库见参考
建议采用
3、数据库名前加“#”；
只需要把数据库文件前名加上#、然后修改数据库连接文件（如conn.asp）中的数据库地址。原理是下载的时候只能识别#号前名的部分，对于后面的自动去掉，比如你要下载：http://www.ylmf.com/date/#123.mdb（假设存在的话）；无论是IE还是FLASHGET等下到的都是http://www.test.com/dat e/index.htm（index.asp、default.jsp等你在IIS设置的首页文档）；另外在数据库文件名中保留一些空格也起到类似作用，由于HTTP协议对地址解析的特殊性，空格会被编码为“%”，如http ://www.test.com/date/123；456.mdb，下载的时http://www. test.com/date/123 %456.mdb。而我们的目录就根本没有123%456.mdb这个文件，所以下载也是无效的这样的修改后，即使你暴露了数据库地址，一般情况下别人也是无法下载！
C. 数据库损坏了怎么办
有的时候因为掉电或者其他原因导致数据库损坏,我们可以使用mysql自带的mysqlcheck命令来快速修复所有的数据库或者特定的数据库;例如
检查优化并修复所有的数据库用:
# mysqlcheck -A -o -r -p
Enter password:
database1 OK
database2 OK
----------
修复指定的数据库用
# mysqlcheck -A -o -r Database_NAME -p
即可
另外如果只是对某个表进行修复可以用：myisamchk或isamchk
其中myisamchk适用于MYISAM类型的数据表，而isamchk适用于ISAM类型的数据表。这两条命令的主要参数相同，一般新的系统都使用MYISAM作为缺省的数据表类型，这里以myisamchk为例子进行说明。当发现某个数据表出现问题时可以使用：
myisamchk tablename.MYI
进行检测，如果需要修复的话，可以使用：
myisamchk -of tablename.MYI
关于myisamchk的详细参数说明，可以参见它的使用帮助。需要注意的时在进行修改时必须确保MySQL服务器没有访问这个数据表，保险的情况下是最好在进行检测时把MySQL服务器Shutdown掉。
另外可以把下面的命令放在你的rc.local里面启动MySQL服务器前：
[ -x /tmp/mysql.sock ] && /pathtochk/myisamchk -of /DATA_DIR/*/*.MYI
其中的/tmp/mysql.sock是MySQL监听的Sock文件位置，对于使用RPM安装的用户应该是 /var/lib/mysql/mysql.sock，对于使用源码安装则是/tmp/mysql.sock可以根据自己的实际情况进行变更，而 pathtochk则是myisamchk所在的位置，DATA_DIR是你的MySQL数据库存放的位置。
1,简单的修复模式
myisamchk -r -q path/数据库/坏表.MYI
注:-r ----恢复模式 -q ----快速修复
2,使用安全修复模式
myisamchk --safe-recover path/数据库/坏表.MYI
3,困难的修复模式
如果在索引文件的第一个16K块被破坏，或包含不正确的信息，或如果索引文件丢失，你只应该到这个阶段 。在这种情况下，创建一个新的索引文件是必要的。按如下这样做：
把数据文件移更安全的地方。
使用表描述文件创建新的(空)数据和索引文件：
shell> mysql db_name
mysql> Delete FROM tbl_name;
mysql> quit
将老的数据文件拷贝到新创建的数据文件之中。（不要只是将老文件移回新文件之中；你要保留一个副本以防某些东西出错。）
回到阶段2。现在myisamchk -r -q应该工作了。（这不应该是一个无限循环)。
4,非常困难的修复模式
只有描述文件也破坏了，你才应该到达这个阶段。这应该从未发生过，因为在表被创建以后，描述文件就不再改变了。
从一个备份恢复描述文件并且回到阶段3。你也可以恢复索引文件并且回到阶段2。对后者，你应该用myisamchk -r启动。
如果你没有一个备份但是确切地知道表是怎样被创建的，在另一个数据库中创建表的一个拷贝。删除新的数据文件，然后从其他数据库将描述和索引文件移到破坏的数据库中。这给了你新的描述和索引文件，但是让数据文件独自留下来了。回到阶段2并且尝试重建索引文件。
5,优化表结构
myisamchk -r 表
也可以使用sql语句来优化OPTIMIZE TABLE
本方法参考自mouse博客
D. 高分求Access 数据库被黑客破坏怎么修复
如果你的asp全都被挂马了，那估计数据库也有马了..
你用记事本打开你的asa数据库，alt+e→P 查找文本功能，查找关键字
"<iframe" //一般菜鸟都是用iframe挂马，就能查找文本咯
因为数据库是二进制，所以你看的时候会有乱码。。但是他修改以后就很麻烦，可能即使你改过来也用不了了，死马当活马医吧
以后别用asp后缀做数据库了，因为黑客可以直接把一句话木马插进去，反而不安全
数据库名字可以用 data#.mdb
（有"#"可以防下载，因为#在浏览器里不解析...但是用url编码也可以解析，当然一般都想不到啦，这样基本就可以防止数据库被下载到咯）
还有问题可以Q我...497521484...我尽量捡会的回答...
祝你好运~~~
E. 服务器远端被人恶意登录，CO数据库被破坏，服务器运行的游戏数据被损毁，请问报警是否可以解决
Minecraft只是一个游戏，对于游戏数据，报警了是一点卵用都没有的，因为那是游戏，不是什么重要数据，这种情况我建议你把服务器安全工作做好，避免下次被破坏。Minecraft服务器发展起来总会遇到熊孩子的，所以要做好防熊工作
F. access数据库被破坏，如何修复
我就遇到过你的这种情况我在网上找了 N 久，如果没有备份的话就歇菜了。
希望你有备份的，下面的方法对你大概没什么作用了
被攻击后的数据库（asa或asp格式的）就算你把网站里的毒杀了后
把格式再改回来也没有用了
网上真的不安全啊
修复ACCESS数据库的几种常见方法:
技术支持部在日常工作中经常会碰到因非正常退出、网络不稳定或病毒等原因造成的Access数据库损坏。损坏了的Access数据库会造成软件运行不稳定，出现各种运行错误，为解决这类问题就必须对Access数据库进行修复。
修复Access数据库，我们一般使用微软Office 97中带的Access 97对数据库进行修复和整理。Access数据库被损坏分以下几种情况：1、严重损坏；2、轻度损坏；3、有些表被损坏或有些表的部分记录被损坏。下面就分情况介绍解决办法。
1、使用Access97打不开数据库、系统提示"不可识别的数据库格式"或"不是该表的索引"等信息，这样的数据库都是损坏比较严重的。损害严重的数据库一般来说都是无法修复的，只有恢复备份了，好在这种情况比较少见。
2、如果数据库损坏的不严重，只需要使用Access 97菜单上的“修复数据库”和“压缩数据库”就可以把数据库修复好。因为数据库轻微损坏的时候，一般也不会导致软件出什么问题，所以也不会引起人的注意，只有当数据库的某一个或几个表损坏了的时候，才会使软件变得不稳定，所以这种情况才是我们最常遇到的。
3、如何确定数据库中哪几个表有问题呢，我们首先利用Access 97建立一个空数据库，利用系统提供的“引入数据库”功能，选择目标数据库所有的表进行引入，Access 97当引入到有问题的表时系统会提示一些错误信息，把这个表的名字记下来以备以后修复时使用。
接下来利用Access97打开有问题的数据库，准备修复表。修复损坏的表的方法依照表损坏程度不同而不同，下面分情况介绍处理的办法：
一、表损坏的非常严重，表现为无法打开表，系统提示“Microsoft jet 找不到对象”、“没有读写权限”或“不可识别”等信息。
处理方法：这种表的已经损坏得非常严重了，一般无法修复。如果这个表不很重要或通常情况下表的内容为空的话，例如“常用凭证表”、“科目共享锁定表”或“凭证共享锁定表”，我们可以通过引入的方法把其他数据库的表引入，然后把有问题的表删除即可。
二、表中有几行内容非常混乱或字段内标有“#已删除”字样，但当要删除这些记录时就会出现错误信息不许删除。
处理办法：既然不让删除这些记录，我们可以通过使用SQL语句把没有问题的记录复制到一个新的表中，然后把老表删除把新表的名字改过来即可。例如“凭证及明细账表GL_ACCVOUCH”中有错误记录有无法删除，我们可以使用如下SQL语句把好的记录复制到GL_ACCTEMP中：
SELECT GL_ACCVOUCH.* INTO GL_ACCTEMP
FROM GL_ACCVOUCH WHERE {筛选的条件}
然后删除表GL_ACCVOUCH，再把表GL_ACCTEMP的名字改为GL_ACCVOUCH即可解决问题。
修复ACCESS数据库的注意事项，首先，我们在修复数据库前一定要做好备份，以防数据丢失或损坏；有一些数据库中有RELATION(关系)来维护数据的一致性，但当数据库异常后相关表的RELATION也就丢失了，在修复好数据库后一定要把RELATION再联好，有些软件可以自动修复RELATION,比如用友公司的ERP8.XX系列产品的数据库可以通过把表accinformation中的[cSysid]='AA' and [项目号]='99'的记录，把[设置值]和[缺省值]改为'8.0A0'，重新进入系统时，系统会自动升级并重建索引。
G. 求助：解决asp.net网站被恶意注入的方法（附后台数据库是sql数据库），该网站已经添加了相关的防火墙
可能是sql注入，xss盲打进后台等等。。。分析攻击手段要日志文件还要网站的源码 只看这个没什么，另外下面的图好蛋疼。能不能把重叠部分的代码贴出来
H. 如何利用sql注入攻击删除文件
一、 SQL注入攻击的简单示例。
statement := "SELECT * FROM Users WHERE Value= " + a_variable + "
上面这条语句是很普通的一条SQL语句，他主要实现的功能就是让用户输入一个员工编号然后查询处这个员工的信息。但是若这条语句被不法攻击者改装过后，就可能成为破坏数据的黑手。如攻击者在输入变量的时候，输入以下内容SA001’;drop table c_order--。那么以上这条SQL语句在执行的时候就变为了SELECT * FROM Users WHERE Value= ‘SA001’;drop table c_order--。
这条语句是什么意思呢?‘SA001’后面的分号表示一个查询的结束和另一条语句的开始。c_order后面的双连字符 指示当前行余下的部分只是一个注释，应该忽略。如果修改后的代码语法正确，则服务器将执行该代码。系统在处理这条语句时，将首先执行查询语句，查到用户编号为SA001 的用户信息。然后，数据将删除表C_ORDER(如果没有其他主键等相关约束，则删除操作就会成功)。只要注入的SQL代码语法正确，便无法采用编程方式来检测篡改。因此，必须验证所有用户输入，并仔细检查在您所用的服务器中执行构造 SQL命令的代码。
二、 SQL注入攻击原理。
可见SQL注入攻击的危害性很大。在讲解其防止办法之前，数据库管理员有必要先了解一下其攻击的原理。这有利于管理员采取有针对性的防治措施。
SQL注入是目前比较常见的针对数据库的一种攻击方式。在这种攻击方式中，攻击者会将一些恶意代码插入到字符串中。然后会通过各种手段将该字符串传递到SQLServer数据库的实例中进行分析和执行。只要这个恶意代码符合SQL语句的规则，则在代码编译与执行的时候，就不会被系统所发现。
SQL注入式攻击的主要形式有两种。一是直接将代码插入到与SQL命令串联在一起并使得其以执行的用户输入变量。上面笔者举的例子就是采用了这种方法。由于其直接与SQL语句捆绑，故也被称为直接注入式攻击法。二是一种间接的攻击方法，它将恶意代码注入要在表中存储或者作为原书据存储的字符串。在存储的字符串中会连接到一个动态的SQL命令中，以执行一些恶意的SQL代码。
注入过程的工作方式是提前终止文本字符串，然后追加一个新的命令。如以直接注入式攻击为例。就是在用户输入变量的时候，先用一个分号结束当前的语句。然后再插入一个恶意SQL语句即可。由于插入的命令可能在执行前追加其他字符串，因此攻击者常常用注释标记“—”来终止注入的字符串。执行时，系统会认为此后语句位注释，故后续的文本将被忽略，不背编译与执行。
三、 SQL注入式攻击的防治。
既然SQL注入式攻击的危害这么大，那么该如何来防治呢?下面这些建议或许对数据库管理员防治SQL注入式攻击有一定的帮助。
1、 普通用户与系统管理员用户的权限要有严格的区分。
如果一个普通用户在使用查询语句中嵌入另一个Drop Table语句，那么是否允许执行呢?由于Drop语句关系到数据库的基本对象，故要操作这个语句用户必须有相关的权限。在权限设计中，对于终端用户，即应用软件的使用者，没有必要给他们数据库对象的建立、删除等权限。那么即使在他们使用SQL语句中带有嵌入式的恶意代码，由于其用户权限的限制，这些代码也将无法被执行。故应用程序在设计的时候，最好把系统管理员的用户与普通用户区分开来。如此可以最大限度的减少注入式攻击对数据库带来的危害。
2、 强迫使用参数化语句。
如果在编写SQL语句的时候，用户输入的变量不是直接嵌入到SQL语句。而是通过参数来传递这个变量的话，那么就可以有效的防治SQL注入式攻击。也就是说，用户的输入绝对不能够直接被嵌入到SQL语句中。与此相反，用户的输入的内容必须进行过滤，或者使用参数化的语句来传递用户输入的变量。参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中。采用这种措施，可以杜绝大部分的SQL注入式攻击。不过可惜的是，现在支持参数化语句的数据库引擎并不多。不过数据库工程师在开发产品的时候要尽量采用参数化语句。
3、 加强对用户输入的验证。
总体来说，防治SQL注入式攻击可以采用两种方法，一是加强对用户输入内容的检查与验证;二是强迫使用参数化语句来传递用户输入的内容。在SQLServer数据库中，有比较多的用户输入内容验证工具，可以帮助管理员来对付SQL注入式攻击。测试字符串变量的内容，只接受所需的值。拒绝包含二进制数据、转义序列和注释字符的输入内容。这有助于防止脚本注入，防止某些缓冲区溢出攻击。测试用户输入内容的大小和数据类型，强制执行适当的限制与转换。这即有助于防止有意造成的缓冲区溢出，对于防治注入式攻击有比较明显的效果。
如可以使用存储过程来验证用户的输入。利用存储过程可以实现对用户输入变量的过滤，如拒绝一些特殊的符号。如以上那个恶意代码中，只要存储过程把那个分号过滤掉，那么这个恶意代码也就没有用武之地了。在执行SQL语句之前，可以通过数据库的存储过程，来拒绝接纳一些特殊的符号。在不影响数据库应用的前提下，应该让数据库拒绝包含以下字符的输入。如分号分隔符，它是SQL注入式攻击的主要帮凶。如注释分隔符。注释只有在数据设计的时候用的到。一般用户的查询语句中没有必要注释的内容，故可以直接把他拒绝掉，通常情况下这么做不会发生意外损失。把以上这些特殊符号拒绝掉，那么即使在SQL语句中嵌入了恶意代码，他们也将毫无作为。
故始终通过测试类型、长度、格式和范围来验证用户输入，过滤用户输入的内容。这是防止SQL注入式攻击的常见并且行之有效的措施。
4、 多多使用SQL Server数据库自带的安全参数。
为了减少注入式攻击对于SQL Server数据库的不良影响，在SQLServer数据库专门设计了相对安全的SQL参数。在数据库设计过程中，工程师要尽量采用这些参数来杜绝恶意的SQL注入式攻击。
如在SQL Server数据库中提供了Parameters集合。这个集合提供了类型检查和长度验证的功能。如果管理员采用了Parameters这个集合的话，则用户输入的内容将被视为字符值而不是可执行代码。即使用户输入的内容中含有可执行代码，则数据库也会过滤掉。因为此时数据库只把它当作普通的字符来处理。使用Parameters集合的另外一个优点是可以强制执行类型和长度检查，范围以外的值将触发异常。如果用户输入的值不符合指定的类型与长度约束，就会发生异常，并报告给管理员。如上面这个案例中，如果员工编号定义的数据类型为字符串型，长度为10个字符。而用户输入的内容虽然也是字符类型的数据，但是其长度达到了20个字符。则此时就会引发异常，因为用户输入的内容长度超过了数据库字段长度的限制。
5、 多层环境如何防治SQL注入式攻击?
在多层应用环境中，用户输入的所有数据都应该在验证之后才能被允许进入到可信区域。未通过验证过程的数据应被数据库拒绝，并向上一层返回一个错误信息。实现多层验证。对无目的的恶意用户采取的预防措施，对坚定的攻击者可能无效。更好的做法是在用户界面和所有跨信任边界的后续点上验证输入。如在客户端应用程序中验证数据可以防止简单的脚本注入。但是，如果下一层认为其输入已通过验证，则任何可以绕过客户端的恶意用户就可以不受限制地访问系统。故对于多层应用环境，在防止注入式攻击的时候，需要各层一起努力，在客户端与数据库端都要采用相应的措施来防治SQL语句的注入式攻击。
6、 必要的情况下使用专业的漏洞扫描工具来寻找可能被攻击的点。
使用专业的漏洞扫描工具，可以帮助管理员来寻找可能被SQL注入式攻击的点。不过漏洞扫描工具只能发现攻击点，而不能够主动起到防御SQL注入攻击的作用。当然这个工具也经常被攻击者拿来使用。如攻击者可以利用这个工具自动搜索攻击目标并实施攻击。为此在必要的情况下，企业应当投资于一些专业的漏洞扫描工具。一个完善的漏洞扫描程序不同于网络扫描程序，它专门查找数据库中的SQL注入式漏洞。最新的漏洞扫描程序可以查找最新发现的漏洞。所以凭借专业的工具，可以帮助管理员发现SQL注入式漏洞，并提醒管理员采取积极的措施来预防SQL注入式攻击。如果攻击者能够发现的SQL注入式漏洞数据库管理员都发现了并采取了积极的措施堵住漏洞，那么攻击者也就无从下手了。
如何防范黑客入侵网站的几种常见安全方法
• 本文的目的是告诉企业在建网站时如何打造一个防范黑客攻击的安全网站
• 互联网随着时间的发展，它的优势越来越来明显，世界越来越多的企业通过这二十四小时不间断的传波平台，打造自己公司的网站，开展电子商务活动；由于互联网的特殊性和复杂性，一旦你企业的网站接入互联网后，你的企业网站便为一个公众场所，任何人都可以上你的企业网站浏览信息，任何人(比如：黑客)都有可能对你的企业网站进行技术上测试，查找你的企业网站在程序设计上的漏洞，不论他目的是恶意还其它原因，你都无法制止他的行为，因为黑客在远程电脑上实施操作。
• 建设一个有安全系数保证的网站，关系着一个企业的商业信誉问题，面临日夜猖狂、日益肆虐的网络攻击事件不断发生，给自己的网站做一些最基本的安全防范措施是非常必要的。
• 非法字符过滤和转换
• 黑客攻击网站之前，先采用探路方式，通过网站的留言、论坛、搜索等系统，注入可执行的web脚本代码和SQL语法，来达到入侵网站的目的；对网站所有交互式接口的文本输入框（如：网站留言系统、BBS系统、blog系统、搜索系统、登陆系统等）的地方采取在客户端非法字符过滤和转换技术，通过非法字符过滤和转换将可执行的恶意代码变为可读HTML代码，使它基本失去了暴破网站的威力，又起到了保护网站程序源代码不受破坏的作用。
• 建一个指定自定义出错(Error)的信息页面
• 好处在于防止网站设计源代码的溢出，黑客在入侵网站的后台管理系统，往往在网页地址栏输入可执行的SQL语法和根据程序员为网页命名的习惯输入网址的文件名，一旦黑客采用这种方式，就会将黑客带向指定自定义出错(Error)的信息页面。
• 拒绝Cookie验证方式
• Cookie的好处在于管理员和注册用户登陆网站时Cookie会保存登陆信息，下次再登陆时Cookie会自动将这些信息保留在登陆的页面输入文本框中，其作用是为了方便登陆者，但也给黑客采集Cookie的信息提供了良机，所以应该拒绝采用客户端Cookie验证登陆方式，而改用通过服务器验证方式登陆并对账号和密码采用单向加密方式保存。
• 不要用自助建网站系统建你的企业网站
• 一些网站设计公司为了增加销量降低成本（其实大部分客户喜欢购买廉价的自助建网站系统），开发不同用途的自助建网站系统（如：网站内容管理、BBS、新闻发布、留言、博客等），同时为了争夺市场、扩大产品知名度，往往两种方式销售产品：个人版可以免费下载；商业版则需要购买；其实两个版本的网站在是同一种程序技术基础开发出来的，商业版是授权验证后可作商业用途，有技术支持和维护保证；黑客通过下载个人版，来潜心深研这些自助建网站系统的开放源代码，从中找出程序漏洞，一旦发现了可攻击的程序漏洞，通过搜索引擎平台检索出同一型号版本自建网站系统，然后就发起攻击；解决方式找有自主能力开发网站公司设计你的企业网站，通过将网站的设计源代码封装成“.dll”组件，这样即保证网站设计上的安全性又保护了源代码，又提高了网站的安全系数同时也降低了网站被入侵的危害程度，因为黑客攻陷网站往往是从研究网站源代码开始并中找出程序漏洞。
• 解决Googel“暴库”问题
• 一些程序员在开发网站喜欢用虚拟路径方法调用数据库，这就必须将数据库保存在开通WWW服务的文件夹下，自然逃不过狡猾黑客的眼睛，一旦黑客破解了数据库的真实保存位置，便可以从浏览器的地址栏打开和下载该数据库，对网站的后果是非常危险的；要想确保你网站的数据库不被黑客下载，只要采取将数据库保存在非WWW服务的文件夹下，通过物理(真实)路径方法调用数据库，就可完全防止黑客下载你企业网站的数据库。
• 建立robots文件
• 为了防止网站的重要文件夹（如：后台管理）和文件（如：纯程序文件）不被搜索引擎所收录，首先在网站根目录下建一个“robots.txt”纯文本文件，来防止网站的重要文件或其它敏感信息被搜索引擎所收录；最大多搜索引擎平台都遵守robots协议；搜索引擎机器人访问网站时，首先找到网站根目录下robots文件，然后会读取robots文件的内容，来确定它对网站收录的范围；robots文件可以说是对搜索引擎机器人收录权限的限制管理，从而避免将网站的重要文件或其它敏感信息暴露在网络上，在网站安全上起一个防御锁作用，robots文件可由网站设计者在遵守robots协议下，根据网站的实际情况自由编写。
• 完全将杜绝黑客的攻击和入侵是不可能的，完全在网站的每个接口过滤和转换非法字符串是办不到，比如，在文件上传时，狡猾黑客会采取躲过过滤和转换非法字符串的办法，将可执行恶意脚本代码保存“.gif”格式或“.jpg”格式来实施文件上传漏洞攻击，解决的方法是对所有上传的文件先导入到“.txt”纯文本文件读一遍，判断是否是可执行恶意脚本代码，如果是就删除，但是网站管理员要有web程序基础；黑客入侵网站的方式变化多端，几千种免费暴破网站的软件，使你企业网站防不胜防，但是以上介绍几种防御措施对菜鸟黑客是可行的，对于一些资深黑客，他也要费一些精力和时间来暴破你企业网站，他会考虑值不值得？毕竟你的网站只是一个企业网站，不是银行和证券交涉现金交易的网站（它们的程序设计安全系数更高），在大多数下情况，“大侠”黑客不会光顾你企业网站。
1、SQL注入漏洞的入侵
这种是ASP+ACCESS的网站入侵方式，通过注入点列出数据库里面管理员的帐号和密码信息，然后猜解出网站的后台地址，然后用帐号和密码登录进去找到文件上传的地方，把ASP木马上传上去，获得一个网站的WEBSHELL。这个是黑链使用的前一部分，应该比较常用吧。现在网上卖webshell的太多了。
2、ASP上传漏洞的利用
这种技术方式是利用一些网站的ASP上传功能来上传ASP木马的一种入侵方式，不少网站都限制了上传文件的类型，一般来说ASP为后缀的文件都不允许上传，但是这种限制是可以被黑客突破的，黑客可以采取COOKIE欺骗的方式来上传ASP木马，获得网站的WEBSHELL权限。
3、后台数据库备份方式获得WEBSHELL
这个主要是利用网站后台对ACCESS数据库进行数据库备份和恢复的功能，备份数据库路径等变量没有过滤导致可以把任何文件的后缀改成ASP，那么利用网站上传的功能上传一个文件名改成JPG或者GIF后缀的ASP木马，然后用这个恢复库备份和恢复的功能把这个木马恢复成ASP文件，从而达到能够获取网站WEBSHELL控制权限的目的。
4、网站旁注入侵
这种技术是通过IP绑定域名查询的功能查出服务器上有多少网站，然后通过一些薄弱的网站实施入侵，拿到权限之后转而控制服务器的其它网站。
下面这几种我就听不懂了，不过有点高技术的站长会看懂的。
5、sa注入点利用的入侵技术
这种是ASP+MSSQL网站的入侵方式，找到有SA权限的SQL注入点，然后用SQL数据库的XP_CMDSHELL的存储扩展来运行系统命令建立系统级别的帐号，然后通过3389登录进去，或者在一台肉鸡上用NC开设一个监听端口，然后用VBS一句话木马下载一个NC到服务器里面，接着运行NC的反向连接命令，让服务器反向连接到远程肉鸡上，这样远程肉鸡就有了一个远程的系统管理员级别的控制权限。
6、sa弱密码的入侵技术
这种方式是用扫描器探测SQL的帐号和密码信息的方式拿到SA的密码，然后用SQLEXEC之类的工具通过1433端口连接到远程服务器上，然后开设系统帐号，通过3389登录。然后这种入侵方式还可以配合WEBSHELL来使用，一般的ASP+MSSQL 网站通常会把MSSQL的连接密码写到一个配置文件当中，这个可以用WEBSHELL来读取配置文件里面的SA密码，然后可以上传一个SQL木马的方式来获取系统的控制权限。
7、提交一句话木马的入侵方式
这种技术方式是对一些数据库地址被改成asp文件的网站来实施入侵的。黑客通过网站的留言版，论坛系统等功能提交一句话木马到数据库里面，然后在木马客户端里面输入这个网站的数据库地址并提交，就可以把一个ASP木马写入到网站里面，获取网站的WEBSHELL权限。
8、论坛漏洞利用入侵方式
这种技术是利用一些论坛存在的安全漏洞来上传ASP木马获得WEBSHELL权限，最典型的就是，动网6.0版本，7.0版本都存在安全漏洞，拿7.0版本来说，注册一个正常的用户，然后用抓包工具抓取用户提交一个ASP文件的COOKIE，然后用明小子之类的软件采取COOKIE欺骗的上传方式就可以上传一个ASP木马，获得网站的WEBSHELL。
I. 数据库老是被别人恶意添加数据，如何防范
去网上搜一下防注入代码．一般注入就是没有过滤好”’”，”or”，”and”，”select”等等
平时数据库中存放管理密码和帐户的表不要命名为admin，user等等
字段也整难点，密码最好是md5加密，然后去www.cmd5.com把加密的密文看看能不能破解．如果不能的话那就是最好的效果！
一般sql注入大都针对asp网站．注入入侵工具最常用的就是明小子和阿D．不知道漏洞是怎么发现的？！
但是利用都是通暴力猜解的，所以表名起的不常见点就猜不出来了！