유닉스 타임 스탬프 (int (11))로 저장된 날짜 정보가있는 데이터베이스로 작업하고 있으며, 지난 X 일 동안의 항목 만 반환합니다. , 예를 들어 지난 90 일. 내가 함께 왔어요 무엇MySQL - 과거 X 일간의 항목 만 반환
은 다음과 같습니다
SELECT * FROM mytable WHERE category=1 AND
FROM_UNIXTIME(time) > DATE_SUB(now(), INTERVAL 91 DAY)
'시간'이 DB에서 INT (11)이다. 이것은 잘 작동하는 것 같지만 다른 사람들이 이것을 어떻게 생각하는지 궁금합니다.
SELECT * FROM mytable WHERE category=1 AND
time > (UNIX_TIMESTAMP() - ((60*60*24)*90))
또는 MYTABLE FROM 단순히
SELECT * WHERE 카테고리 = 1 AND 시간> (UNIX_TIMESTAMP() - (86,400 * 90))이있는
이 단지 수를 비교한다 (초 케이스)
그냥 큰 소리로 생각하면 ... 다른 방법으로하면 DB에 대한 작업이 줄어 듭니다.
TO_UNIXTIME 분명히 MySQL의 내 버전과 존재하지 않습니다 :) –
죄송합니다 ... 나는 unix_timestamp 의미 : – Zed
그것은 심지어 일광 절약 시간입니다 - 구하다. – flaschenpost
이 쿼리는 인덱스를 사용하는 모든 행의 날짜 변환이 MySQL에서 필요하므로 두통을 일으킬 수 있습니다. Unix 타임 스탬프는 숫자이므로 타임 스탬프를 다른 날짜 형식으로 변환하는 대신 조회 날짜를 유닉스 타임 스탬프로 변환하십시오.
내 테스트 쿼리가 0.0046 초 근처에서 실행 중입니다. 위의 첫 번째 질문에 대한 원래의 쿼리와 쿼리 모두 시간에별로 차이가 없습니다. –
나는 그것이 확실하다고 생각하지만, 100-500k 테스트 레코드를 테이블에로드 한 다음 실행 시간을 확인하십시오. 또한, 0.0046은 캐시 된 쿼리의 실행 시간이 될 수 있습니다. 행 수가 많고 일부 매개 변수를 변경 한 다음 쿼리를 다시 실행하면 –
내 테스트 쿼리가 SELECT * 였고 일부 임의의 열로 변경되어 실행되었습니다. 0.0044 초. 나는 같은 무작위 열에서 1 년 전으로 돌아가도록 쿼리를 변경했으며, 가장 빠른 쿼리 인 0.0025 초에 599 개의 레코드가 반환되었습니다. 불행히도, 나는 어떤 테스트 레코드도 가지고 있지 않고, db에있는 레코드들만을 가지고있다. (그러나 꽤 좋은 크기이다.) –
타임 스탬프를 int로 저장하는 이유는 무엇입니까? mysql이 가지고있는 많은 Date Time functions을 사용할 수 있기 때문에 mysql DATETIME 데이터 유형을 사용할 것입니다.
이 필드의 데이터 형식을 제어 할 수 없다면 쿼리를 수행하고 비교하기 전에 날짜를 유닉스 타임 스탬프 int로 변환합니다.
그것이 완료된 방법이고 나는이 시점에서 그것을 변경하는 것이 편안하지 않습니다. 쿼리가 0.0046 초 근처에서 실행되므로 성능 문제가 아닌 것 같습니다. –
감사합니다. 그냥 시도해보세요. 잘 작동하는 것 같습니다. –
또한 더 빨리 작동합니다. (시간 자체가 아니라 시간 함수를 비교하기 때문에) 여러분의 경우에는 불가능한'time'에 인덱스를 사용할 수 있습니다. **그러나**! 그것은 매우 이상한 인간의 취미로 일광 절약 시간으로 큰 문제가 있습니다. 그건 시간이 지남에 IT에 수십억 달러의 비용이 있어야합니다 ... – flaschenpost