TypeORM 性能问题 - 加载具有许多关系的对象答案

【问题标题】：TypeORM Performance problem - Loading object with many relationsTypeORM 性能问题 - 加载具有许多关系的对象
【发布时间】：2023-03-08 23:05:02
【问题描述】：

TS + Node 12 + TypeORM + MySQL - AWS 2GB 实例 EC2（我认为中等）

问题很简单。

对于获取订单 API 请求 - 我们从数据库加载订单 - 每个订单都带有来自其他表的更多相关字段 - 通过连接。比如：

const galleries: Gallery[] = await relationshipAModel.createQueryBuilder('model')
      .leftJoinAndSelect('model.subRelationshipA', 'a')
      .leftJoinAndSelect('model.subRelationshipB', 'b')
      .whereInIds(firstResultIds)
      .getMany();

代码来自：https://github.com/typeorm/typeorm/issues/4499

我们的问题与此处链接的问题完全相同。

NodeJS 进程在加载 5-10 个请求时崩溃 - 每个请求加载 500 个订单 - 加载 25 / 50 / 100 个订单是可以的。

内存分析没有帮助。

打字稿中的订单对象如下所示：

@Entity()
export class Order {
@PrimaryColumn({ type: 'varchar', name: 'id' })
id: string;

@OneToMany(type => OrderItem, orderItem => orderItem.order, {
    cascade: true
})
orderItems: OrderItem[];

@ManyToOne(type => ServiceLevel, serviceLevel => serviceLevel.orders, {
    cascade: true
})
serviceLevel: ServiceLevel;

@ManyToOne(type => Customer, customer => customer.orders, { cascade: true })
customer: Customer;

@JoinColumn()
@OneToOne(type => Address, { cascade: true, nullable: true })
shippingAddress: Address;

@JoinColumn()
@OneToOne(type => Address, { cascade: true, nullable: true })
billingAddress: Address;

@ManyToMany(type => OrderTag, orderTag => orderTag.orders, {
    cascade: true
})
@JoinTable()
orderTags: OrderTag[];

只留下“可疑”的字段

350 个订单的节点堆堆栈：

Nov 25 15:24:58 ip-172-31-38-186 web: {
Nov 25 15:24:58 ip-172-31-38-186 web: page: 0,
Nov 25 15:24:58 ip-172-31-38-186 web: maxResults: 350,
Nov 25 15:24:58 ip-172-31-38-186 web: filters: [ { fieldName: 'orderStatus', operator: 'NOT IN', values: [Array] } ],
Nov 25 15:24:58 ip-172-31-38-186 web: stepFilter: { fieldName: 'orderStatus', operator: 'IN', values: [ 'stepPrint' ] },
Nov 25 15:24:58 ip-172-31-38-186 web: sortFields: [ { fieldName: 'createdDate', value: 'DESC' } ]
Nov 25 15:24:58 ip-172-31-38-186 web: }
Nov 25 15:25:18 ip-172-31-38-186 web: <--- Last few GCs --->
Nov 25 15:25:18 ip-172-31-38-186 web: [20326:0x31ad300]   113205 ms: Mark-sweep 993.9 (999.1) -> 993.7 (997.4) MB, 766.6 / 0.0 ms  (+ 127.3 ms in 23 steps since start of marking, biggest step 25.9 ms, walltime since start of marking 969 ms) (average mu = 0.231, current mu = 0.082) allocation [20326:0x31ad300]   114167 ms: Mark-sweep 994.1 (997.4) -> 993.2 (997.1) MB, 881.2 / 0.0 ms  (+ 47.2 ms in 7 steps since start of marking, biggest step 26.7 ms, walltime since start of marking 963 ms) (average mu = 0.138, current mu = 0.036) allocation fa
Nov 25 15:25:18 ip-172-31-38-186 web: <--- JS stacktrace --->
Nov 25 15:25:18 ip-172-31-38-186 web: ==== JS stack trace =========================================
Nov 25 15:25:18 ip-172-31-38-186 web: 0: ExitFrame [pc: 0x13555cd]
Nov 25 15:25:18 ip-172-31-38-186 web: Security context: 0x003cbef008d1 <JSObject>
Nov 25 15:25:18 ip-172-31-38-186 web: 1: slice [0x2c5dd3dc3561] [buffer.js:~606] [pc=0xb6e02716b7c](this=0x3b080493db19 <Object map = 0x3047472a6099>,0x3b0942d12c71 <Uint8Array map = 0x3047472a55a9>,44922,45232)
Nov 25 15:25:18 ip-172-31-38-186 web: 2: _typeCast(aka typeCast) [0x20293188c3e9] [/var/app/current/node_modules/mysql/lib/protocol/packets/RowDataPacket.js:~53] [pc=0xb6e027ab692](this=0x338ac1d1b739 <RowDataPacket map =...
Nov 25 15:25:18 ip-172-31-38-186 web: FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
Nov 25 15:25:18 ip-172-31-38-186 web: 1: 0xa093f0 node::Abort() [node]
Nov 25 15:25:18 ip-172-31-38-186 web: 2: 0xa097fc node::OnFatalError(char const*, char const*) [node]
Nov 25 15:25:18 ip-172-31-38-186 web: 3: 0xb842ae v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
Nov 25 15:25:18 ip-172-31-38-186 web: 4: 0xb84629 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
Nov 25 15:25:18 ip-172-31-38-186 web: 5: 0xd30fe5  [node]
Nov 25 15:25:18 ip-172-31-38-186 web: 6: 0xd31676 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [node]
Nov 25 15:25:18 ip-172-31-38-186 web: 7: 0xd3def5 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [node]
Nov 25 15:25:18 ip-172-31-38-186 web: 8: 0xd3eda5 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
Nov 25 15:25:18 ip-172-31-38-186 web: 9: 0xd4185c v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [nod
e]

任何帮助将不胜感激！

【问题讨论】：

请提供来自SHOW CREATE TABLE 的SQL。可能可以改进多对多表，如下所述：mysql.rjweb.org/doc.php/…
谢谢@RickJames - 这里是 - pastebin.com/3WiBcmQb - 告诉我
典型的id 是什么样的？（VARCHAR(255) 听起来不太好。） 5 唯一键？可能设计不好。如果一个只有一个账单地址的人想把东西寄给他的女朋友，而把东西寄给另一个女朋友怎么办？让我们也看看查询的 SQL。
再次感谢@RickJames。 id 由 shop_id + 商店的订单号组成，类似于“1_882972974”。有什么建议让它变得更好吗？而且 - 你能详细说明 5 个唯一键有什么问题吗？我很快就会得到 SQL 查询。
添加了查询@RickJames - pastebin.com/m8yvVHq4 Again - 非常感谢

标签： mysql node.js typescript query-performance typeorm

【解决方案1】：

如果id 是PRIMARY KEY 的order，则DISTINCT 是不必要的。

LIMIT 应该有一个ORDER BY。

order需要

 INDEX(shopId, orderBatchId, id)

100 行 100 列？这似乎很多。重新考虑您真正需要哪些列以及是否需要 100 行。

是否有 nodejs 或“数据包”或其他网络限制？（因为 100 行，但 500 呱呱。）

5 个唯一键意味着可能有一个单独的表，将其中的 4 个等同于一个。这也意味着可能存在设计错误；我评论了另一个shipping_addr 和billing_addr 都是UNIQUE 的问题。如果我试图给两个不同地址的亲戚寄东西，我会遇到麻烦。特别是如果其他人正在使用您的系统发送到这些地址中的任何一个。

即使是 3 UNIQUEs 也可能是一个错误。我知道非常 2 个 UNIQUEs 的有效案例；常见的是“标准化”。

这个结构让我头晕目眩。我需要弄清楚它是否符合您的要求：

FROM a  LEFT JOIN b  INNER JOIN c

如果这相当于这个，那么你没有你想要的：

FROM a  LEFT JOIN (b  INNER JOIN c)

另一方面，这可能是您想要的：

FROM (a  LEFT JOIN b)  INNER JOIN c

这会更清楚，特别是因为c 是一个子查询：

FROM (c  JOIN a)  LEFT JOIN b

请提供EXPLAIN SELECT ...，以便我们查看评估结果。

同时，如果你能得到子查询first，我的窘境就避免了。它可能有助于提高性能。

LEFT -- 你使用LEFT JOIN 是因为这些东西都可能缺少数据吗？例如，shippingAddress 是否会丢失（而您期待NULLs）？我问是因为它对性能、可读性、优化等有影响。需要时使用LEFT，否则不要。

【讨论】：