루머, 의견, 소문, 사실, 버전 관련 벤치마크, 개인적인 경험 등...

다중 스레드는 처리량을 향상시킬 수 있지만 다음과 같은 제한 사항이 있습니다.

• 처리량 상한은 이론상 한계의 약 절반입니다. (귀하의 "특정 비율") (이것은 멀티 스레드 패키지를 기반으로 한 벤치마크입니다. 이름은 잊어버렸습니다. 10년 전이었습니다.)
• 여러 스레드는 뮤텍스 및 기타 필요한 잠금 메커니즘에서 서로 경쟁합니다.
• 5.7부터 시작하면 64개 스레드가 MySQL의 멀티스레딩 제한이며, 이를 초과하면 처리량이 정체되거나 심지어 저하됩니다. (출처: 많은 Oracle 벤치마크에서는 한 버전이 이전 버전보다 훨씬 우수하다고 자랑합니다.) (한편 스레드당 대기 시간은 최고 수준입니다.)
• 가능하다면 각 스레드는 데이터를 일괄 처리해야 합니다.

일괄 처리:

• LOAD DATA 是一次从单个线程 INSERT 大量行的最快方法。但是，如果您包括将文件写入 LOAD 비용으로 인해 일괄 삽입보다 속도가 느려질 수 있습니다.
• 배치 INSERT가 이어집니다. 그러나 특정 한도 또는 "수익률 감소"에 도달하면 "수백" 행으로 제한됩니다.
• 일괄 삽입은 쿼리당 한 행을 삽입하는 것보다 10배 빠릅니다. 따라서 고속 수집에 사용(또는 LOAD DATA)할 가치가 있습니다. (출처: 많은 INSERT 查询插入一行的速度的 10 倍。因此，它（或 LOAD DATA 다양한 시간 제한 테스트.)

일부 데이터 소스는 한 번에 한 행만 전송해야 합니다(예: N초마다 차량의 센서 데이터). 이를 위해서는 데이터를 일괄 처리하기 위한 중간 계층이 필요합니다.
데이터 수집에 대한 토론:
• http://mysql.rjweb.org/doc.php /staging_table

정규화는 디스크 공간을 줄이는 데 유용하며 일괄적으로 수행하는 것이 가장 좋습니다.
• 표준화를 참조하세요.
• 결국 오래된 데이터를 지우는 것 외에는 거의 유용하지 않습니다. PARTITIONing파티션을 참조하세요.
거대한 "사실" 테이블은 검색하기 어렵습니다. 수집할 때 요약 데이터 구축을 고려하세요.
• 요약 테이블
위 처리를 수행한 다음 원본 데이터를 버릴 수도 있습니다. 하루에 테라바이트의 데이터를 얻는 것 같습니다.