Doctrine原生SQL需用$em->getConnection()->executeStatement()参与事务，参数用?占位；DQL返回DTO用NEW操作符，构造函数参数顺序须匹配；多库需在doctrine.yaml配置多个entity_managers；findBy()排序用实体属性名而非列名。
Doctrine ORM里怎么写原生SQL又不破坏事务一致性
直接用 $connection->executeStatement() 会绕过ORM的变更追踪和二级缓存，但事务本身仍受管理——前提是别手动调用 $connection->beginTransaction()。正确做法是复用当前EntityManager绑定的连接：
- 用
$em->getConnection()->executeStatement('UPDATE user SET status = ? WHERE id = ?', [1, 123])，它自动参与当前事务 - 如果需要返回结果集，改用
executeQuery()+fetchAllAssociative() - 注意：参数必须用问号占位符，命名参数（
:status）在原生SQL中不被自动解析，得手动传给executeQuery($sql, $params, $types) - 执行后记得清空相关实体的代理状态，否则后续
$em->find()可能返回脏数据：调用$em->getUnitOfWork()->clear()或针对性$em->detach($entity)
如何让DQL查询返回DTO而不是实体对象
DQL本身不支持直接构造任意PHP类，但Doctrine提供 NEW 操作符实现轻量投影：
- 写法：
SELECT NEW App\Dto\UserSummary(u.name, u.email) FROM User u WHERE u.active = true - DTO类必须有匹配参数顺序的构造函数，且命名空间要完整（不能用use缩写）
- 不能用
partial u.{id,name}混搭，NEW必须是查询根表达式 - 性能上比全实体略快（跳过代理初始化和生命周期回调），但丢失了懒加载能力——DTO就是纯数据容器
- 如果DTO字段来自关联表，确保JOIN已声明，否则DQL报错：例如
SELECT NEW ... FROM User u JOIN u.profile p
Symfony项目里怎么配置多个数据库连接并切换EntityManager
Doctrine Bundle支持多连接，但每个连接默认只配一个EntityManager；想一库一EM，得显式定义：
- 在
doctrine.yaml里用entity_managers键分别声明，例如default和analytics，各自指定connection名 - 连接名需在
connections下提前定义，包括host、dbname等，不同库可共用同个driver但必须隔离dbname - 服务注入时用
@doctrine.orm.analytics_entity_manager而不是@doctrine.orm.default_entity_manager - 注意：跨库JOIN在DQL中不被支持，只能靠应用层组合查询结果
- 事务无法跨连接生效——
$em1->transactional()和$em2->transactional()是独立的，需用SaaS级分布式事务方案（如Saga）补足
为什么findBy()加了orderBy还是不生效
findBy() 的第二个参数是排序数组，但底层调用的是DQL的 ORDER BY 子句，而DQL对字段引用极其严格：
- 必须用实体属性名（非数据库列名）：例如
['createdAt' => 'DESC']，而不是['created_at' => 'DESC'] - 关联字段需用点号语法：
['profile.status' => 'ASC']，前提是已在实体中定义profile关系 - 复合排序要传索引数组：
['status' => 'ASC', 'updatedAt' => 'DESC']，关联键顺序即SQL中ORDER BY顺序 - 如果实体用了继承映射（InheritanceType），
findBy()默认只查具体类型，排序字段若在父类可能被忽略——此时应改用DQL或QueryBuilder - 缓存开启时，
findBy()结果可能被复用，排序失效；加['cache' => false]参数强制跳过查询缓存
复杂排序逻辑别硬塞 findBy()，QueryBuilder才是可控路径。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
