在typeorm中仍需掌握sql语言，因为sql是理解数据库底层、处理复杂查询和性能优化的关键。1. orm并非万能，面对复杂关联、聚合或数据库特有功能时，sql能更高效准确地表达意图；2. 性能优化依赖对sql的理解，需通过执行计划分析和手动优化查询来提升效率；3. 数据迁移、修复及存储过程等场景离不开sql的直接操作。在typeorm中可通过queryrunner.query()或repository.query()执行参数化原生sql防止注入，也可用createquerybuilder()构建复杂查询并嵌入sql片段，结合typescript接口定义查询结果类型，实现编译时类型检查，提升代码安全性与可维护性，最终形成sql与typeorm相辅相成的高效开发模式。
在现代TypeScript数据库开发中，SQL语言与TypeORM框架并非对立，而是相辅相成。TypeORM为我们提供了强大的ORM能力，极大地简化了数据库操作，但SQL语言的核心作用从未被取代，它依然是理解数据库底层逻辑、处理复杂查询和优化性能的关键。TypeScript则为这一切带来了类型安全与卓越的开发体验。
解决方案
在TypeORM的生态里，SQL语言扮演着多重角色。它既是TypeORM内部生成查询的基石，也是开发者在需要精细控制或处理ORM难以覆盖的场景时，直接与数据库沟通的桥梁。TypeORM通过其
QueryBuilder、原生SQL查询方法（如
queryRunner.query()或
repository.query()）以及自定义Repository等机制，允许我们灵活地嵌入和执行SQL。
这意味着，当我们面对简单的CRUD操作时，可以充分利用TypeORM的实体和Repository模式，享受高度抽象带来的便捷。但当业务逻辑涉及复杂的聚合、窗口函数、递归查询，或者需要对特定数据库特性进行深度优化时，直接编写SQL并结合TypeScript的类型定义，就成了提升效率和确保正确性的不二法门。例如，我经常会遇到一些报表需求，ORM生成的JOIN语句性能并不理想，这时直接手写一个优化过的SQL视图或存储过程，再通过TypeORM调用，效果会好得多。TypeScript在这里的作用，就是为这些原生SQL的输入参数和输出结果提供类型约束，让原本“盲盒”式的SQL调用变得可控、可预测，大大降低了运行时错误的风险。
为什么在TypeORM中仍需掌握SQL语言？
说实话，很多人一开始接触ORM，会觉得终于可以摆脱SQL的束缚了。但实际项目跑起来，你会发现SQL的价值远超想象。在我看来，即便有了TypeORM这样优秀的ORM框架，掌握SQL语言依然是现代数据库开发者的核心竞争力。
首先，ORM并非万能。它擅长处理结构化、相对简单的CRUD操作，但面对复杂的业务逻辑，比如多表深度关联、复杂的聚合统计、地理空间查询，或者利用数据库特有的函数和索引提示时，ORM生成的SQL往往不够高效，甚至无法表达你的意图。我曾在一个电商项目中遇到过一个复杂的库存分配逻辑，涉及到多个维度和时间序列的计算，尝试用ORM的
QueryBuilder去构建，代码量巨大且难以理解，最终还是回到了直接编写优化过的SQL，再通过TypeORM执行，效率和可读性都得到了显著提升。
其次，性能优化离不开SQL。当你的应用面临性能瓶颈时，很多时候问题出在数据库查询上。这时候，你需要能够阅读和理解ORM生成的SQL，甚至手写SQL来利用索引、优化JOIN顺序、避免全表扫描。如果你不了解SQL，就无法深入分析数据库的执行计划，更无从谈起优化。这就像你开一辆自动挡的车，虽然不用手动换挡，但如果你连发动机的工作原理都不懂，车子出问题了你可能就束手无策。
再者，数据库迁移、数据修复、特定数据库特性利用等场景，都离不开SQL。TypeORM可以帮助你管理Schema迁移，但当需要手动处理数据、批量更新或利用数据库特有的存储过程、触发器时，SQL就是你的直接工具。理解SQL，让你能够更全面、更深入地掌控你的数据层。
如何在TypeORM中高效地编写和执行原生SQL查询？
在TypeORM中执行原生SQL，其实有几种非常实用的方式，每种都有其适用场景。
最直接的方式是使用
queryRunner.query()或
repository.query()。这两种方法允许你直接传入SQL字符串并执行。比如：
import { getManager, getRepository } from "typeorm";
import { User } from "./entity/User"; // 假设你有User实体
async function executeRawSql() {
const entityManager = getManager(); // 获取EntityManager
const userRepository = getRepository(User); // 获取特定实体的Repository
// 方式一：使用entityManager执行任意SQL
const result1 = await entityManager.query(`SELECT id, name FROM user WHERE age > ?`, [25]);
console.log("Raw query result (entityManager):", result1);
// 方式二：使用repository执行SQL，返回结果通常是对象数组
const result2 = await userRepository.query(`SELECT * FROM user WHERE email LIKE ?`, ['%@example.com']);
console.log("Raw query result (repository):", result2);
// 复杂查询示例：使用JOIN和聚合
const complexResult = await entityManager.query(`
SELECT u.name, COUNT(p.id) AS post_count
FROM user u
LEFT JOIN post p ON u.id = p.userId
GROUP BY u.id
HAVING COUNT(p.id) > ?
`, [5]);
console.log("Complex query result:", complexResult);
}这里需要注意的是，参数化查询（使用
?或
$1等占位符）是最佳实践，可以有效防止SQL注入攻击。
另一种非常强大的方式是使用
createQueryBuilder()。虽然它不是纯粹的原生SQL，但它提供了一种链式调用的API来构建SQL查询，同时保留了TypeORM的类型安全优势。你可以用它来构建复杂的JOIN、WHERE、GROUP BY、HAVING等子句，并且在需要时，它也允许你插入原生SQL片段。
import { getRepository } from "typeorm";
import { User } from "./entity/User";
import { Post } from "./entity/Post"; // 假设有Post实体
async function useQueryBuilder() {
const userRepository = getRepository(User);
// 使用QueryBuilder构建复杂查询
const usersWithPosts = await userRepository
.createQueryBuilder("user") // "user" 是别名
.leftJoinAndSelect("user.posts", "post") // 关联并选择posts
.where("user.age > :minAge", { minAge: 30 })
.andWhere("post.createdAt > :date", { date: new Date('2023-01-01') })
.orderBy("user.name", "ASC")
.getMany(); // 获取多个结果
console.log("Users with posts (QueryBuilder):", usersWithPosts);
// QueryBuilder中插入原生SQL片段
const customFunctionResult = await userRepository
.createQueryBuilder("user")
.select("user.name", "userName")
.addSelect("LOWER(user.email)", "lowerEmail") // 使用原生SQL函数
.where("user.id IN (:...ids)", { ids: [1, 2, 3] })
.getRawMany(); // 获取原始数据，不映射到实体
console.log("Custom function result (QueryBuilder raw):", customFunctionResult);
}getRawMany()或
getRawOne()在需要获取非实体映射的原始数据时特别有用，比如只查询特定列或聚合函数的结果。
TypeScript如何提升SQL开发体验与代码可维护性？
TypeScript为SQL开发带来的最大福音，无疑是类型安全。当我们在TypeORM中编写SQL时，TypeScript可以在编译时就捕捉到许多潜在的错误，这比等到运行时才发现要高效得多。
考虑一个场景，你执行了一个原生SQL查询，返回的数据结构可能不是你某个实体类型能直接映射的。这时，你可以利用TypeScript的接口（Interface）来明确定义SQL查询的预期结果结构：
// 定义原生SQL查询结果的接口
interface UserPostCount {
userName: string;
postCount: number;
}
async function getAggregatedData(): Promise<UserPostCount[]> {
const entityManager = getManager();
const result = await entityManager.query<UserPostCount[]>(`
SELECT u.name AS userName, COUNT(p.id) AS postCount
FROM user u
LEFT JOIN post p ON u.id = p.userId
GROUP BY u.id
ORDER BY postCount DESC
`);
return result;
}
async function processData() {
const data = await getAggregatedData();
// 此时，data是UserPostCount[]类型，你可以安全地访问data[0].userName或data[0].postCount
data.forEach(item => {
console.log(`${item.userName} has ${item.postCount} posts.`);
});
}通过这种方式，即使是原生SQL的返回结果，也获得了类型提示和编译时检查，大大减少了因字段名拼写错误、类型不匹配等问题导致的运行时崩溃。IDE也能提供智能提示，提升开发效率。
此外，TypeScript的模块化特性和接口定义，也让复杂的SQL逻辑更容易被组织和复用。你可以将常用的SQL片段或查询结果类型定义在独立的模块中，使得代码结构更清晰。当数据库Schema发生变化时，如果你的TypeORM实体或自定义接口与SQL查询紧密关联，TypeScript的类型检查机制会立即指出哪些地方需要更新，从而提升了代码的可维护性和重构的信心。这种“早发现、早治疗”的机制，是JavaScript所不具备的，也是TypeScript在现代数据库开发中不可或缺的价值。
