제가 초보라 .. mysql(mariadb) 에서 쿼리를 할때
id가 2019283,2930102,3092812831,239203182... (이런게 1000)개
라고 하면 where in (2019283,2930102,3092812831,239203182..) 이런식으로
쿼리를 하는데 이렇게 하는게 맞는건지요 ? 지금은 limit 가 대폭 상향 조정 되었지만
찾아보면 기존엔 where in 에서 limit 도 있었던거 같고..
where in 을 그냥 쓰면 되는건지? 아니면 대체 할 방법이 있는건지
갑자기 궁금해서 .. 여쭤봅니다.
in 안의 내용이 서브쿼리( select 결과)이니 대응되는 쿼리로 바꾸셔도 상관없습니다
그리고 limt는 데이터의 디스크상의 배치와 사상되는게 다르니 사용을 권장하지 않습니다.(누락되는게 생길수 있기 때문입니다)
규칙성 찾는게 어려우시면 일부 규칙이 성립하는것을 대상으로 뷰를 생성하시는것도 한방법입니다.
마구잡이로 넣지 않았을테니, DB설계문서를 확인하시는게 좋겠습니다.
201903041111 이런식으로 ..
시간별로 쌓여져있고 ..
등록된 주문중 1000개를.. 상태 변경 하려면.. 데이터에서 1000개를 선택해서 post 로 받아서 그걸 where in 으로 검색해서
상태를 update하는데요 ..
시간에 따른 값이기 때문에 규칙성이 없습니다...
백엔드 코드를 적절히 활용해서 Entry를 1,000개씩 분리해서 개별 SQL로 실행하시면 될 것 같습니다.
타 DBMS에서는 in 절 내에 1,000개가 넘는 entry는 넣지 못 하도록 권고/방지 되어있습니다.
OR를 사용해서 1,000개 이상의 entry를 수용할 수 있긴 합니다.
근데 해당 방법보다는 서브쿼리가 낫지 않을까 조심스레 의견 전달드립니다.
랜덤인데요 주문번호가.. 그리고 limit 1000개 한도는 없어졌습니다.
mysql 이나 mariada나
In 절1000개 한계는 없는걸로 아는데
실행 쿼리 길이제한이 있습니다.
택배 생각 하시면 편합니다...
물건 등록하면.. 주문번호가 부여 됩니다..
10000개가 .. 등록 됐고 ..
1000개가 집하 되면..
그 집하된 제품을.. 바코드로 .. 선택해서
상태 변경 하는겁니다... 입고 완료로
1000개는 랜덤이죠
일반적 환경에서는 주문 1건 단위로 처리 됩니다.
I/F에서 주문번호 입력에 취소등 검사해 이상이 없으면
주문상태 변경하고 정상을 리턴하죠.
대량의 IN절을 사용할 업무는
보통 존재하지 않는데...
찾아봐도 .. max_allow_packet 관련 얘기만 나오는데 ..
post 값과 관련된 값 같은데 ..post 패킷 사이즈만 키워주면..
되는줄 알았는데 mysql 에 쿼리 길이 제한이 있나요?
뭐 아주 많이 할 일은 없긴 합니다만.. 제한이 있다면 알아두면
좋을것 같아서요.
In절 or문. Union문장. 텍스트 입력/수정 등 아주 긴 쿼리를 쓰면
가끔 오류를 볼 수 있습니다.
https://www.google.com/url?sa=t&source=web&rct=j&url=https://ckbcorp.tistory.com/689&ved=2ahUKEwjqjMr53KTiAhWK7GEKHUrHB0oQFjADegQIAhAB&usg=AOvVaw0kFY7n0vrRDXDW0RTACJRi&cshid=1558170484946
해당 row들의 공통점을 찾아서 select하는것이 힘들다면 임시테이블을 통해서 서브쿼리로 수행하심이 좋을 듯 합니다
CREATE TEMPORARY TABLE `tmp` (
`idx` int not null,
primary key(`idx`)
) engine = memory;
임시테이블을 생성하시고 in clause에 해당하는 데이터를 bulk insert해주시구요
select * from `xx` as `a`
inner join `tmp` as `b` ON `a`.`idx` = `b`.`idx`
또는
select * from `xx` where `idx` in (select `idx` from `tmp`)
업무도 빠삭해야되고 프로그래밍도 짬도 되야되고 서로 관계된 테이블 전부 고려해야되고 항상 머리 싸메는거 보고 있습니다.
데이터가 몇백기가에서 테라바이트까지 되다보니 성능쪽도 고려해야 되고 하다보니 그팀은 10년 이상 짬되는 직원들만 구성 되었습니다.