위키백과:쿼리/아카이브 요청 2

이것은 과거 토론의 기록이다.이 페이지의 내용을 편집하지 마십시오.새로운 토론을 시작하거나 오래된 토론을 다시 시작하려면 현재 토크 페이지에서 다시 시작하십시오.

아카이브 1

아카이브 2

특정 제목 형식을 사용하여 토폰어 기사 목록 식별

안녕.

위키백과에서 앞서 논의한 내용:명명 규칙(지리적 이름)#세르비아 마을 이름 형식, 세르비아의 마을에 대한 불분명한 표시 형식에 차이가 있다.범주 아래에 있는 기본 네임스페이스의 모든 기사 목록을 작성하는 데 도움을 줄 수 있는가?세르비아의 인구 밀집 지역 및 정규 표현식 /\(.*\)$/?그리고 나서 우리는 잘못된 긍정이나 부정적인 면이 없는지 확인하기 위해 목록을 수정할 수 있었고, 대량 이동을 위해 이것을 올릴 수 있었다.

마찬가지로, 쿼리가 가용 자원에 너무 많은 부담을 주지 않는다면 카테고리 아래에 있는 기사와 유사한 작업을 수행할 수 있다.보스니아와 헤르체고비나의 인구 밀집 지역들, 같은 이슈를 가지고 있다(대량 이동의 영향이 거기에 있을 수 있는지 보는 것은 좋을 것이다).

TIA! --조이 [shallot] (토크) 07:21, 2021년 4월 1일 (UTC)[응답]

조이, 이게 네가 찾는 거면 알려줘.

• https://petscan.wmflabs.org/?psid=snf60409
• https://petscan.wmflabs.org/?psid=sv60420

다른 형식(예: TXT 또는 CSV)으로 저장하려면 출력 탭으로 이동하여 원하는 항목을 선택한 다음 쿼리를 다시 실행하십시오.나는 너의 RegEx를 조정했다..*\(.*\)$ 범주 깊이를 10으로 설정하면 모든 것을 포함할 수 있을 만큼 충분히 깊은지 실험해 볼 수 있다.비마을이 데이터에 많이 섞여 있는 것 같은데...나는 일부 심층적인 하위 카테고리 및/또는 그들의 기사가 주의를 필요로 할 수 있다고 생각한다.예를 들어, Probus(황제)는 Category:마침 세르비아에 위치한 로마의 도시였던 시리뮴.아마도 추가적인 카테고리나 다른 레지엑스가 이러한 비마을들을 제거하는데 도움이 될 것이다.–Novm Languageae(대화) 07:53, 2021년 4월 1일(UTC)[응답]

흠, 깊이 2가 효과가 있을 것 같군. 그리고 나서 분류 자체를 정리하기 위해 관리 일을 좀 해야겠어.고마워!@No no that user : 자유롭게 가입 :) --조이 [shallot] (대화) 10:42, 2021년 4월 1일 (UTC)[응답]

@Joy: 잠깐 훑어보면 보스니아 헤르체고비나(주체들 때문에)는 최소한 3의 깊이가 필요할 것이다.조금 더 나은 regex는 대문자 모호한 용어만을 보여주는 것이다.요즘 좀 바쁜데 수동 필터링은 큰 일 같지 않아.그 결과를 누군가의 사용자 페이지에 저장할까?해당사용자(대화)없음(UTC) 13:30, 2021년 4월 1일 (UTC)[응답]

지난 365일 동안 편집 횟수가 가장 많은 사용자(디버그)

Chlod와 나는 이 질문에 대해 작업했지만, 두 시도 모두 시간이 초과되었다.여기 암호가 있다.속도를 높일만한 제안은 없나?수정표가 10억줄로 되어 있는 것 같아서 꽤 큰 테이블이야.또한 빠른 쿼리를 위해 인덱싱/키잉된 열에서 WHERE, GROUP BY, ORDER BY를 실행해야 한다고 어디선가 읽었지만, 현재 그 세 개 모두 키가 아닌 열에서 실행 중이다.SQL Optimizer 도구는 쿼리 계획 1.1에서 filesort 또는 임시 테이블을 사용하고 있음 이것은 보통 비효율적인 질의를 나타낸다. 쿼리가 느리면 사용 가능한 인덱스를 활용하여 파일 정렬을 피하십시오.–Novm Languageae(대화) 17:09, 2021년 4월 2일(UTC)[응답]

먼저 날짜 형식이 잘못됨 - rev.rev.rev_timestamp(및 이 db의 다른 모든 타임스탬프)는 YYYYMMDDHHMMSS 형식으로 저장되며 UNIX_TIMestamp()는 시대 이후 초입니다.DATE_FORMAT(DATE_ADD(NOW()), Interval -1년, "%Y%m%d"와 같은 것을 원할 것이다.%H%i%s"), UNIX_TIMestamp()가 아님 - 365*24*60*60.

그러나 이 수정이 고정되어 있더라도 이 쿼리는 (몇 일 후, 적어도 며칠 후) 지난 해의 모든 사용자 및 그 시간 동안 한 개라도 편집한 ips의 편집 수를 보여준다.데이터를 수집하는 순간이라고 해도 결과를 전송하는 데만 여전히 매우 오랜 시간이 걸릴 것이다.그래서 있다.

사용자 수를 제한할 수 있는 다른 방법(아마도 user_editcount > 일부 적절한 숫자)을 가진 사용자만 허용한다고 가정할 경우, 최소 rev_id를 먼저 찾은 다음 rev_timestamp 대신 rev_timestamp로 쿼리함으로써 더 빠른 결과를 얻을 수 있을 것이다.채석:query/53813은 이 방법으로 마지막 한 시간의 결과를 얻었다; 나는 5분 후에 rev_timestamp에서 직접 동등한 질의를 기다리는 것을 중단했다.

(또한, revision_user index는 내가 위에서 제안했던 대로 user_editcount 또는 사용자 테이블의 다른 값으로 제한을 시작하는 것일 수도 있지만, 여기서 revision_user index는 개정보다 유용하지 않다.)—크립틱 17:37, 2021년 4월 2일 (UTC)[응답]

그리고 어려운 부분은 빼먹었다. 데이터 볼륨 때문에 수정기호(또는 로깅) 테이블의 쿼리 속도가 느리고 쿼리되는 데이터의 양과 관련하여 선형적이지 않다.제한시간을 한 달로 늘리는 것(그리고 편집수가 가장 많은 20개만 표시)은 8분 30초가 걸렸다; 따라서 1년 전으로 거슬러 올라가면 적어도 1시간 30분이 걸릴 것이다. 이것은 채석리의 제한시간을 훨씬 넘는 것이고, 나는 토올랩에 대해서도 직접적으로 생각한다.아마 한 달짜리 덩어리로 쪼개서 후처리에 고정시킬 수 있을 것이다.—크립틱 18:33, 2021년 4월 2일 (UTC)[응답]

크립틱, 고마워이렇게 방대한 SQL 데이터베이스로 작업하는 건 처음이야.많이 배우고 있다.자세한 설명은 고맙다.사령관 워터포드, 이 질문은 결국 비실용적이었던 것 같군–Novem Languageae (대화) 18:44, 2021년 4월 2일 (UTC)[응답]

흠. 이 자료를 얻을 수 있는 방법이 있을 거야.@Firefly fyi CommanderWaterford (대화) 18:52, 2021년 4월 2일 (UTC)[응답하라]

대략적인 대답을 위해, 위키피디아의 1년 전 개정판을 가져오는 것은 어떨까?편집 횟수/1–1000명별 위키백과 목록 및 현재 개정판과 비교? -- John of Reading (토크) 19:30, 2021년 4월 2일 (UTC)[응답]

첫 번째 단계에서는 좋은 생각이지만, 예를 들어:-)와 같은 사용자들은 여기에 1년 미만일 것이다.CommanderWaterford (대화) 20:54, 2021년 4월 2일 (UTC)[응답]

기록을 위해, Chlod는 LIMIT 1000을 추가하여 Cryptic의 쿼리 버전을 받았다.모두 고마워.이것은 좋은 학습 경험이었다.–Novm Languageae(대화) 21:59, 2021년 4월 2일(UTC)[응답]

2.48시간(8936.40초) 후, 즉...Chlod(Say hi!) 00:09, 2021년 4월 3일 (UTC)[응답하라]

하! 내 앞에 실제 인간이 여섯 명 있어.BD2412 T 04:45, 2021년 4월 5일 (UTC)[응답]

지난 2일 이내에 생성된 모든 페이지({Uncategorate} 태그 포함)

내 접근 방식은 다음과 같은 범주에서 페이지를 확인하는 것이었습니다.추가 참고 자료가 필요한 모든 기사.나는 Petscan을 시도해 보았지만, 만들어진 날짜에 대한 필터를 찾을 수 없었다.채석리를 써봤는데 대부분 작동했는데 날짜에 따라 필터링이 안 되더라고페이지 테이블에 만든 날짜 필드가 없다는 게 놀랍다.도와주시면 감사하겠다.간단한 해결책을 놓쳤다고 나를 때리더라도 :-) –Novem Languageae (대화) 12:16, 2021년 4월 12일 (UTC)[응답]

Novm Languageae, 이 정렬된 검색으로 충분할까? --Trialpears (대화) 12:34, 2021년 4월 12일 (UTC)[응답]

시험관들, 하하, 나는 뭔가 간단한 것을 놓쳤을지도 모른다는 느낌이 들었다.당신의 통찰력에 대단히 감사하다.SQL 조회도 수정하고 싶을 경우를 대비해서 열어둘게.주로 SQL에서 내가 잘못한 것을 배울 수 있도록. –Novem Languageae (토크) 20:36, 2021년 4월 12일 (UTC)[응답]

그 질의는 지난 이틀 동안 편집이 0인 페이지가 아니라 적어도 1개의 편집이 있는 페이지와 일치할 것으로 보인다.AND rc_new=1을 추가해 보십시오.또한 페이지에 가입할 필요가 없다; rc_cur_id, rc_namespace, rc_title은 모두 page_id, page_namespace, page_title에 직접 매핑되어야 한다(아마도 이동이 없는 경우?나는 최근의 변화상을 사용해 본 적이 없고, 그것의 진부함을 모른다.

"새로운 페이지"를 구성하는 것은 어떤 경우에도 약간 모호하다.예를 들어, 초안의 페이지를 메인 스페이스로 이동하시겠습니까?rc_new도 WHERE NOTERY(SELECT 1 FROM revision Where here rev_page_id AND rev_timestamp < /*something*/)도 그것을 감지할 수 없다.페이지 지정 테이블이 도움이 될 수도 있지만, 그것에 대한 어떤 문서도 찾을 수 없어.—크립틱 21:02, 2021년 4월 12일 (UTC)[응답]

고마워 크립틱혹시 궁금해서 페이지트라이어지 테이블 문서를 찾은 것 같아. mw:확장:PageTriage/pagetregation_log_table.하단의 내비게이션 박스에 추가 테이블이 있다.또한 SQL 쿼리가 작동하게 되었다.여기 기록상 입니다.–Novm Languageae(대화) 04:01, 2021년 4월 13일 (UTC)[응답]

그건 그냥 내가 찾은 타입의 쓰레기장이고, 내가 직접 도망칠 수도 있었어.복제본은 테이블 자체를 뷰 뒤에 숨기기 때문에 키 열을 표시하지 않지만, 합성 지수에서 필드의 조합과 순서를 볼 수 없으면 실제로 유용하지 않다.필드의 의미론도 설명되어 있지 않기 때문에 추측(혹은 확장 소스를 읽어야 한다)하지 않고는 데이터가 무엇을 의미하는지 알 길이 없다.비교 mw:설명서:Revision table.—크립틱 14:12, 2021년 4월 13일 (UTC)[응답]

오래전에 기사에 올려진 무기한 이동단백질

10년 전, 첫 컷오프로서?위키백과의 경우:마을 펌프(제안)#이동방지페이지 이동대상 –xeno^talk 21:33, 2021년 4월 26일 (UTC)[응답]

제노, 진행중이야.1) 조회 1 - 이동 보호되는 모든 페이지(sysop만 해당)2만3251쪽, 대부분 유통기한이 없다.2) 조회 2 - 이동 보호되는 모든 페이지(시냅만 해당), 마지막으로 날짜 보호를 위한 열이 설정된 페이지.이번 건은 천천히 진행 중인데 시간이 좀 걸릴지도 몰라.누구든지 그것을 지게 하고 속도를 높이려 한다.3) 질의 3 - 지난 10년 동안 보호되었던 결과를 없애라.SQL에서 이것을 할 좋은 방법은 아직 생각해보지 못했어.나는 노력했다.WHERE MAX(log_timestamp) < DATE_FORMAT(DATE_ADD(NOW(), INTERVAL -10 YEAR), "%Y%m%d%H%i%s"), 그러나 그것은 좋아하지 않았다.WHERE MAX , [1]당.다시 말하지만, 만약 좋은 해결책을 본 사람이 있다면, 주저하지 말고 포크를 달고 게시해라.고마워요.–Novem Languageae(대화) 22:41, 2021년 4월 26일 (UTC)[응답]

Novm Languageae 고마워, 나는 그 질의에 문제가 있다고 생각해.유용한 집합은 사용자:가 있는 무한정 이동 보호된 페이지일 수 있다.보호 로그에 나와 있는 나울린위키.–xeno^talk 22:44, 2021년 4월 26일 (UTC)[응답]

두 가지 질문에 모두 문제가 있다.54375에서 pr_id는 page_restriction의 기본 키로 pr_id와는 관계가 없으며 pr_page를 원한다.54378년:

• 네임스페이스를 혼합하므로 로그 테이블과 페이지 테이블에서 모두 쿼리가 색인화되지 않았을 뿐만 아니라, 예: 4, Talk:4, User:4, User:4, Template:4, Template Talk:4, Book:4, Book Talk:4, Book Talk:4, Book Talk:4, Book Talk:4, Book Talk:4와 Book Talk:4와 Book Talk:4와 같다.
• 아무 것도 그룹화하지 않아서 한 페이지만 보일 겁니다.
• 보호 추가나 수정뿐만 아니라 보호와 관련된 모든 유형의 가장 최근의 로그 항목을 보여주고 있다.

일하는 질의는 어렵다.페이지 이동에 따르므로(보호 바를 이동한 다음 Foo로 이동하면 로그 항목이 없고, 보호되는 Bar의 리디렉션이 아니라 Foo로 이동하면 Foo에 대한 로그 항목이 없음) log_page는 2009년 10월에 추가되었을 뿐이기 때문에 log_page는 log_namespace/log_title 대신 log_page에 가입하는 것이 이상적이다.그때도 현재 sysop으로 이동 보호되고 있는 31701페이지 중 보호 로그 항목이 전혀 없는 931페이지(쿼리:query/54382)밖에 보이지 않는다.그리고 다른 방향(특히 log_page별 해당 보호 로그 항목 없이 이동 보호된 페이지를 찾는 방향)에서 접근하면 11803개(검역:query/54383)만 볼 수 있다.그래서 나도 뭔가 잘못하고 있어.

(BTW, DATE_FORMAT()은 문자열만 반환하므로, 정확한 시간에 관심이 없다면 log_timestamp <= '2011년 또는 그 정도') —Cryptic 00:48, 2021년 4월 27일(UTC)[응답]

• 11803을 보면, 무기한으로 보호되는 결과를 제외하는 것이 가장 좋을 것이다.–xeno^talk 00:59, 2021년 4월 27일(UTC)[응답]
  • 26개를 제외한 모든 것이 무기한이며, 이 중 5개만 2027년 이전에 만료된다(검역:query/54385).
    2009년 10월 이후 페이지의 채석장:query/54384에 대한 결과.나는 왜 그 결과가 질의 54382와 그렇게 다른지 모르겠다; 그것들은 같아야 한다.—크립틱 01:06, 2021년 4월 27일 (UTC)[응답]
    • 오, 듀, 나는 54382년에 내가 Novm Languageae의 질의에서 지적한 것과 똑같은 pr_id/pr_page 혼동을 만들었다.—크립틱 01:14, 2021년 4월 27일 (UTC)[응답]
    • 그리고 다시 읽어보면, 당신은 더 말이 되는, 자발적인 움직임 보호가 아닌, 자발적인 편집 보호에 대해 묻고 있었다.결과는 여전히 채석장:query/54385에 있다.—크립틱 01:33, 2021년 4월 27일 (UTC)[응답]

      하, 무작위로 고르는 건 어때?Fantasy_Empires (sysop ; 확인) –xeno^talk 01:49, 2021년 4월 27일 (UTC)[응답]

      리스트 고마워!A suggested refinement: " ideally a table of: PAGENAME, EDIT PROTECTION LEVEL, MOVE PROTECTION LEVEL, LAST PROTECTION LOG DATE, LAST PROTECTION LOG REASON, LAST PROTECTING SYSOP, and possible "ISREDIRECT?" for these page would be nice, for the set of pages where (NS:0 && editprotection NOT sysop && moveprotection IS sysop)."(이들 중 일부는 크립틱스의 이전 진술로 인해 배제될 수도 있다고 생각한다.) –xeno^talk 16:04, 2021년 4월 27일 (UTC)[응답]

      두 기본 쿼리에 page_is_redirect 및 현재 편집 보호 수준(있는 경우)을 추가했으며 10/2009 이전 쿼리에 대한 로그 항목에 대한 최적의 추측을 추가했다.마지막 보호 sysop은 로그 항목과 독립적으로 추출할 수 없으므로 100% 신뢰성이 없다.이동 보호 수준은 초기 조건이었기 때문에 항상 sysop이다.ns=0 및 편집 보호 != sysop은 정렬에서 추출할 수 있지만, 10/2009 이전 쿼리를 위해 쿼리:query/54423에서 필터링했다. 10/2009 이후 쿼리에 대해서도 같은 작업을 수행해야 하는가?—크립틱 20:01, 2021년 4월 27일 (UTC)[응답]

      나는 이것이 우리에게 계속 할 수 있는 많은 것을 줄 것이라고 생각한다 - 우리는 후기 결과에 필터링을 사용할 수 있다: 고마워! –xeno^talk 20:11, 2021년 4월 27일 (UTC)[응답]

      채석장:1994/54424.—크립틱 20:19, 2021년 4월 27일 (UTC)[응답]

      크립틱, 페이지뷰를 기준으로 페이지를 걸러내는 것이 가능한가?— 알렉시스 재즈 (말이나 핑) 00:42, 2021년 4월 28일 (UTC)[응답]

      내가 아는 한 그렇지 않다.—크립틱 01:23, 2021년 4월 28일 (UTC)[응답]

참조 태그를 단 적이 없는 가장 오래된 기사

토마스 목장은 위키피디아에 15년 이상 존재해왔으며, 하나의 인라인 참조도 없이, 그리고 독립적인 출처와의 외부 연결도 없이 삭제되려고 한다.그루브 스미스는 조금 더 길긴 했지만 비슷한 상태에 오랫동안 있었다.나는 용의자의 기사를 찾다가가 아니라 토마스라는 이름과 스미스라는 성을 중심으로 전반적인 정리를 하다가 우연히 이 두 사람을 만나게 되었다.이런 상태로 얼마나 더 많은 기사가 실릴까?기술적으로 실현 가능하다면, 가장 좋은 방법은 나이별로 분류된, 그 존재 과정 동안 인라인 참조 태그를 갖지 않은 기사의 목록을 만들어, 가장 오래된 기사에서부터 앞으로 밀고 나가는 것이 될 것이라고 제안한다.누군가 위키푸를 가지고 있으면, 그런 리스트를 만들어 내라.BD2412 T 02:42, 2021년 4월 5일 (UTC)[응답]

참고: WP에서 추후 논의 시:VPT, 예를 들어, 우리는 이것을 2007년 이전이나 2006년 이전에 만들어진 기사들로 제한할 수 있다.분명히, 현재 참조 태그가 있는 모든 기사는 이력을 보기 전에 처음부터 삭제될 수 있다(그러나 이 날짜 이전에 최초로 작성된 현재 참조되지 않은 기사 목록을 생성하는 것으로 충분할 수 있다).BD2412T 03:04, 2021년 4월 5일 (UTC)[응답]

복제본이 원하는 정보를 가지고 있지 않은 경우: 페이지에 참조 태그가 있는지 확인할 수 있는 방법이 없거나, 이전 버전의 페이지로부터 기록 페이지에 표시된 것보다 더 많은 데이터를 가져올 수 있는 방법이 없는 경우.원칙적으로 우리가 여기에 올 수 있는 가장 가까운 것은 현재 어떠한 외부 링크도 없는 기사들의 목록을 만드는 것이다.그 이전에는 가장 빠른 개정으로 직접 검색(이미 페이지 목록을 가지고 있을 때 쉽게 구할 수 있지만)이 효율적으로 이루어지기 어렵고, 정확히 어떤 것이 기사로 적합한지 정의하기가 어렵다.첫 번째 단서로서, 채석장:query/53880은 주 네임스페이스에 페이지가 있으며, 진정한 리디렉션이나 진정한 혼란 또는 카테고리에 있지 않다.모든 세트 인덱스 기사, 현재 외부 링크가 없으며 첫 번째 개정판이 2002년 이전이다.여전히 대부분 연도 기사와 잘못된 긍정이었습니다.—크립틱 03:45, 2021년 4월 5일 (UTC)[응답]

나는 가장 즉각적인 사건들은 그 범주에 분류된 기사로 더욱 좁혀진 질의에 의해 잡힐 수 있다고 생각한다.회사 카테고리 트리 또는 카테고리로 분류된 문서:살아 있는 사람들.위에서 언급된 두 기사는 실제로 ("외부 링크" 섹션에) 외부 링크를 가지고 있지만, 이것은 그들의 회사/개인 웹사이트에 대한 것이다. 그것이 내가 ref 태그의 부재를 집중하게 만들었다.궁금한데, 어떤 기사가 외부로 연결돼 있는지 어떻게 알 수 있을까?예를 들어, "참고" 섹션이 없는 기사를 볼 수 있는가?BD2412T 04:42, 2021년 4월 5일 (UTC)[응답]

모든 페이지의 모든 외부 링크를 나열하여 특수:링크 검색.우리는 단면을 볼 수 없다.—크립틱 12:54, 2021년 4월 5일 (UTC)[응답]

아주 흥미롭군, 고마워.BD2412T 15:18, 2021년 4월 5일 (UTC)[응답]

이 아이디어는 최근 시작된 WP와 전체적인 방향과 동일하다.SWIP 프로젝트.– 우안팔라(토크)

나는 가장 즉각적인 사건들은 그 범주에 분류된 기사로 더욱 좁혀진 질의에 의해 잡힐 수 있다고 생각한다.회사 카테고리 트리 또는 카테고리로 분류된 문서:살아 있는 사람들.생활인 카테고리가 잘 먹힐 것 같지만, 회사 카테고리 트리를 파헤치면 몇 단계만 지나면 대부분 흙이 나온다는 것을 알게 됐다.컴퍼니나 회사 인포박스가 있는 기사들을 잡는 데 더 성공적일 거라고 생각해.이 물품 세트는 매우 깨끗하다.2021년 4월 8일 메가퍼터(대화) 23시 50분 샘 at 메가퍼터(대화)[응답]

2019년, 나는 덧붙인 봇을 썼다.{{unreferenced}}1만 개에 이르는 물품그것은 더 많은 것을 추가할 수 있었지만, RfC 동안 공동체는 의심스러웠거나 보수적이었다. 그리고 나는 그것을 가장 극단적인 사례로 되돌렸다.따라서 페이지의 어떤 외부 링크는 외부 링크 섹션 또는 템플릿에서 변환된 infobox의 단일 외부 링크를 포함하여 태그가 지정되지 않도록 했다.그것이 실행된 후, 불량 태그에 대한 불평은 없었다.단면과 본체를 구분할 수 있다.태그 대신 목록을 만들 수 있다.6백만 명 이상의 말뭉치들이 후보들을 찾아 헤매고 있다.이것은 쉬운 것처럼 들리지만 트리벌 봇이 아니다. 끝없는 에지 케이스 예외가 있다. 예를 들어, dab 대 기사로서 중요한 것은 무엇인가?그것을 보면 전혀 분명하지 않다.그리고 찾을 수 있는 외부 링크 템플릿도 많다.용도가 빌드된 응용 프로그램이 필요한 쿼리는 수행할 수 없다.더 나쁜 것을 찾아 보자는 제안은 흥미롭지만, 나는 대부분의 기사들이 더 나쁜 것으로 태그가 되어 있는 것을 의심한다.{{unreferenced}}항상 그래왔다. -- GreenC 02:33, 2021년 4월 9일 (UTC)[응답하라]

• 참고 항목: https://en.wikipedia.org/wiki/Category:Articles_lacking_sources --Coin945 (토크) 15:34, 2021년 5월 29일 (UTC)[응답]

가장 많이 본 스텁/스타트 클래스 기사

WP:코어 콘테스트의 토론에서, 나는 가장 많이 보는 위키백과 기사의 목록을 시작 수업 이하 혹은 그 이하로 제안했는데, 아마도 독자들의 쇄신에 대한 관심기사들이 우리의 평판에 맞는 중요한 기사들이 될 것이기 때문이다.분명히 최근의 뉴스 기사들 때문에만 두드러지는 기사들을 걸러내는 것이 유용할지도 모른다.위키백과의 삶을 통해 보다 일관된 페이지 뷰를 가진 사람들을 위해 Ron DeSantis(뷰)하루하루 페이지뷰에 대한 어떤 표준편차를 선택할 수 있을까?참고: 때때로 다른 위키백과 제목과 다른 등급 등급으로 분류된 기사.다양한 위키피디아 과목의 최고 등급이 맞는다는 점에서 코드화할 수 있는가? (때로는 다시 분류되지만 다른 위키피디아 과목은 따라잡지 못하는 경우도 있다) 이들 중 많은 수가 제대로 분류되지 않았을 수 있기 때문에 나는 중요한 과목에 대해 너무 걱정하지 않을 것이다.

--코인945 (대화) 15:42, 2021년 5월 29일 (UTC)[응답]

무기한 생성 보호 물품

안녕, 이거 왜 안 돼?나는 무기한으로 생성 보호되는 모든 기사들의 목록을 sysop 수준에서 생성하려고 한다.무정부상태 (대화) 10:09, 2021년 6월 4일 (UTC)[응답]

페이지가 존재하지 않는다면 페이지 테이블에는 페이지에 대한 행이 없을 것이다.그리고 생성 보호는 페이지_제한(대부분 그러한 이유로)에 저장되지 않고 보호되는_제목에 저장된다.* FROM pt_expiry = 'infinity' AND pt_create_perm = 'sysop' AND pt_namespace = 0; — Cryptic 10:18, 2021년 6월 4일(UTC)[응답]

여러분은 또한 사실상 무기한인 한, 2030년 이후에 10페이지의 제작이 만료로 보호되고 2025년에서 2030년 사이에 21페이지가 더 추가되는 기간 동안(모든 것이 메인 스페이스나 시스템 전용은 아님)을 위해 무언가를 넣는 것을 원할지도 모른다.—크립틱 10:35, 2021년 6월 4일 (UTC)[응답]

채석장이 필요없으니 Special:보호됨제목. --trialpears (talk) 10:20, 2021년 6월 4일 (UTC)[응답]

지속시간별로 걸러낼 방법이 있다면, 나는 그것을 보지 못한다.—크립틱 10:23, 2021년 6월 4일 (UTC)[응답]

오, 그건 특별한 일인가봐.보호 페이지. --Trialpears (대화) 10:31, 2021년 6월 4일(UTC)[응답]

알고 보니 여기선 별로 차이가 없어.메인 네임스페이스에서 41,166페이지가 시솝에 무한정 소금에 절여져 있고, 104페이지에 불과하고, 지속 기간이 정해져 있어.—크립틱 10:39, 2021년 6월 4일 (UTC)[응답]

고마워, 크립틱. 완벽하게 작동해.무정부상태 (대화) 11시 38분, 2021년 6월 4일 (UTC)[응답]

Wiki Project 스위프에 대한 도움말 컴파일 목록

위키백과의 토론에 참여하십시오.위키프로젝트 § 2021년 6월 후속 조치.{{u Sdkb}}^talk 21:48, 2021년 6월 4일 (UTC)[응답]

2004년 9월 20일 이전에 <역사에서 10개의 비소수 편집>이 있는 페이지를 만들기 위한 질의가 실행되는데 2.5시간이 걸렸다.링크된 스레드에 따르면, 우리는 2004년이 아닌 2012년과 동등한 질의를 원한다.이 질문은 분명히 규모가 크지 않다.그것을 최적화할 수 있는 방법은 없을까?cc @크립틱.– SD0001 (대화) 03:54, 2021년 6월 7일 (UTC)[응답]

내 경험 이상으로.채석장:query/55737에서와 같이 가장 바깥쪽 서브쿼리(슈퍼쿼리?) 대신에 HAV 조항을 사용하는 것이 도움이 될 수도 있지만, 나는 그렇게 생각하지 않는다.이것은 더 나은 기준이 필요하다: 효율적으로 질의하기 어렵고 선택적이지 않은 것 외에도 20120920과 초기 질의에서 최소한 10배 이상의 조회수를 기록할 것이다. 여기서 10명이 찾는 것보다 훨씬 큰 숫자가 아니라면, 페이지의 수정 횟수는 얼마나 많은 편집자들이 그것을 검토했는지를 보여주는 좋은 지표는 아니다.—크립틱 06:06, 2021년 6월 7일 (UTC)[응답]

@Cryptic, 우리가 어떤 종류의 더 나은 기준을 사용할 수 있는지 아는 것 없나?우리는 많은 것들을 브레인스토밍했고, 그것에 근거하여 제한을 두는 것이 가장 유망해 보였다.전반적으로 큰 사업이기 때문에 세트 규모가 클 것으로 예상되기 때문에, 큰 성과가 반드시 뭔가 잘못된 것을 나타내지는 않는다.우리는 또한 현 시점에서 전체 목록이 필요한 것은 아니다. 단지 목록 크기가 얼마나 될 것인가와 그 목록 위에 있을 페이지의 종류에 대한 샘플만 세면 된다.{{u Sdkb}}} 17:21, 2021년 6월 7일 (UTC)[응답]

나는 너무 많은 페이지의 편집 이력을 db가 통째로 끌어들이지 못하도록 그것을 리팩터링하고 적절한 장소에 LIMIT을 설정하는 것이 핵심인 채석장:query/56101로 런타임을 2시간으로 향상시킬 수 있었다.WHERE 조건을 더 많이 적용하면 더 개선될 수 있다.sub1출력의 대부분을 차지하고 있는 혼란스러운 페이지를 걸러내는 것과 같은.– SD0001 (대화) 07:47, 2021년 6월 20일 (UTC)[응답]

알고 보니 난장판을 걸러내는 건 속도를 내지 못했어.거의 같은 시간: 채석장:query/56118. – SD0001 (대화) 10:06, 2021년 6월 20일 (UTC)[응답]

c:카테고리:애니메이션 PNG

여보세요!

c:Category talk의 SQL 코드:애니메이션 PNG는 작동하지 않았다.고칠 줄 아는 사람 있어?목표는 모든 애니메이션 PNG를 찾는 것이다.존테밀 (대화) 18:17, 2021년 9월 3일 (UTC)[응답]

어떻게 안 먹혔어?애니메이션 png가 아닌 이미지, 또는 이미 카테고리에 있는 이미지, 애니메이션 png가 아닌 이미지, 또는 결과 없이 영원히 실행되는 이미지를 나열하지 않았는가?전체 결과는 빠르지 않을 것이다. 350만 줄에 불과하며, 더 이상 속도를 높일 수 있는 좋은 방법이 없다. 그러나 "LIMIT 1"을 끝까지 타켓으로 연결하면 c:파일:3번째 순서 인터모드 애니메이션(썸네일)몇 초 후에 png, 내가 보기엔 어떤게 맞는거 같아?—크립틱 22:38, 2021년 9월 3일 (UTC)[응답]

65초 만에 28개의 안타를 쳐냈어

그 중 어느 것도 범주에 속하지 않고, 거의 모든 것이 애니메이션 png이다.c:파일:골든 멜로디 어워드 28번째 인덱스9..png 및 c:File:Зонтаг АП Путешествие в Луну.png look like bad data: the first's img_metadata starts 'a:6:{s:10:"frameCount";i:1;' instead of i:0, and the second 'a:6:{s:10:"frameCount";i:19;' despite not being animated at all.네가 할 수 있는 건 아무것도 없어. 다시 업로드해서 더 잘 발견되길 바라는 것 말고는.조회 수가 너무 적어서 좀 놀랐는데, 찾아냈어야 하는데 못 찾았으면 링크 좀 해 줘.—크립틱 23:02, 2021년 9월 3일 (UTC)[응답]

@Cryptic:Nvm, 지금 28개의 결과를 기다려야 했나 봐.존테밀(대화) 01:19, 2021년 9월 4일 (UTC)[응답]

사용되지 않는 템플릿 리포트

여보세요, 이건 데이터베이스 보고서 페이지의 토크 페이지에 있는 요청인데, 저쪽에서는 답변이 안 들어왔어.사용하지 않는 템플릿의 백로그를 처리할 미사용 템플릿 태스크 포스를 만들기 위해 Wiki Project 템플릿에 대한 전반적인 제안 논의의 일환이다.

나는 원래의 논의에 따라 4개의 보고서를 요청했고, 나는 그것들을 여기서 다시 설명할 것이다.

태스크포스(TF)가 현재 아이디어 단계에 있는 만큼 적어도 두 달 이상 보고서가 실행됐으면 한다.보고서가 언제 만료될 예정인지, 가능하다면 언제 나올지 알려주고 싶다.사용되지 않는 템플리트 데이터베이스에서 다음 4개의 보고서가 필요함:

1) 스텁 또는 리디렉션이 아닌 사용되지 않는 모든 템플릿

2) 사용되지 않은 것으로 나열된 모든 스텁 템플릿토크 페이지 토론의 사용자 중 한 명에 따르면, 정확히 또는 약 1,000개의 스텁 템플릿이 있다고 한다.

3) 미사용으로 나열된 모든 리디렉션토크 페이지 토론의 사용자 중 한 명에 따르면, 정확히 또는 약 6만 9천 개의 리디렉션이 있다고 한다.

4) 작년과 올해에 생성 및/또는 편집된 템플릿. --WikiCleanerMan (토크) 13:23, 2021년 9월 28일 (UTC)[응답]

당신은 이것이 정기적으로 필요한가 아니면 일회성 질의가 괜찮은가?—크립틱 22:08, 2021년 10월 18일 (UTC)[응답]

날짜 태그가 필요할 수 있는 미국 관련 기사

이 목록을 세분화하려고 함(Category:미국은 아직 {{mdy date} 또는 {{dmy date}}}이(가) 없는 3단계까지 다른 국가에서 하위 분류된 모든 기사를 삭제한다.또한 DMY 형식의 날짜가 포함된 모든 기사를 참조문 밖에서 삭제하는 것도 좋을 것이다.둘 중 하나 또는 둘 다 가능할까?{{u Sdkb}}} 19:08, 2021년 10월 18일 (UTC)[응답]

Petscan이 기사 텍스트에 액세스할 수 없는 것과 같은 이유로 쿼리와 함께 임시로 지정되지 않은 날짜 형식으로 제외할 수 없다.

다른 나라에 의한 제외는 가능하지만, "카테고리: 카테고리:미국" - 나는 이 범주에서 다음과 같은 것을 생각한다.대륙수목별 국가들, 깊이 5까지?—크립틱 22:18, 2021년 10월 18일 (UTC)[응답]

@Cryptic, Category에 있는 기사는 어떨까?3개 국가의 이름을 따서 명명된 위키백과 범주(카테고리:A 국가 이전의 미국 및 7개 범주(예: 종속 영토의 이름을 딴 위키백과 범주)?{{u Sdkb}}^talk 22:46, 2021년 10월 18일 (UTC)[응답]

이러한 하위 카테고리를 제외하는 것은 183841개의 기사들과 비교했을 때, 181004개의 기사들을 제외하는 것이 별로 도움이 되지 않는다. (연성 리디렉션이나 혼란스러운 것들을 배제하지 않았기 때문에 Petscan 결과보다 약간 더)아직 전체 리스트를 원하십니까?3000개 미만의 히트를 제거하는 것은 내가 당신 위치에 있다면 클릭 가능한 링크를 잃을 가치가 없을 것이다.—크립틱 01:13, 2021년 10월 19일 (UTC)[응답]

그래, 그래.나는 그것을 위해 봇 작업을 제안하려고 하고 있고, 몇몇 편집자들이 날짜 형식에 대해 얼마나 열정적으로 신경을 쓰는지 발견하려고 한다.그래서 비록 개인적으로 비극이라고 생각하지는 않지만, 예를 들어 두 범주의 기사는 다음과 같다.미국에서 개발된 비디오 게임 및 카테고리:캐나다에서 개발된 비디오 게임은 MSY라는 꼬리표가 붙는데, 이 기사들을 풀장에서 삭제하는 것은 합의를 이루기 위한 희망을 갖기 위해 매우 필요할 것이다.건배, {{u Sdkb}}^talk 01:48, 2021년 10월 19일 (UTC)[응답]

이메일 보내주셨어요.—크립틱 02:08, 2021년 10월 19일 (UTC)[응답]

나는 캐나다 기사가 카테고리:와 같은 mdy 날짜 형식으로 대량 변경되는 것에 반대한다.비디오 게임은 캐나다에서 개발되었다.캐나다는 dmy와 mdy 사이에 선호도가 없으며, MOS:DATTS는 캐나다와 관련된 조항은 각 조항 내에서 (항상 그렇듯이) 일관성을 가진 두 가지 형식 중 하나를 사용할 수 있다고 분명히 밝히고 있다.우리는 캐나다 기사에 MOS를 상대로 표준 날짜 형식을 적용해서는 안 되고, 캐나다가 mdy 날짜를 독점적으로 사용하지 않는다는 사실에 반해서도 안 된다.요셉2302 (대화) 15:03, 2021년 10월 19일 (UTC)[응답]

그래, 그래서 내가 이런 질문을 한 거야.명확하지 않으면 캐나다(또는 다른 나라) 기사를 영향을 받을 목록에서 삭제하는 겁니다.{{u Sdkb}}^talk15:54, 2021년 10월 19일 (UTC)[응답]

좋아, 그럼 미국 기사만 태그할 생각이라면 :) 조셉2302 (대화) 16:01, 2021년 10월 19일 (UTC)[응답]

그런 생각:) 목록의 하위 집합(전체적으로 붙여넣기에는 너무 큼)은 User:Sdkb/sandbox/테스트 페이지.현장검사에서 오류가 발견되지 않았는데, 확인되면 알려줘.{{u Sdkb}}^talk 16:13, 2021년 10월 19일 (UTC)[응답]

여기 당신의 샌드박스 페이지에서 {{use dmy date}}}에 "surething" 후보가 아닌 것으로 보이는 몇 가지 기사가 있다: 캐나다와 미국 언어 협회, 캐나다 연방당, 프랑스 선박 생 레미, 프랑스 선박 보몽.– Jonsey95 (대화) 16:31, 2021년 10월 19일 (UTC)[응답]

흠. 우리가 보고 있는 것은 카테고리 트리가 충분히 깊은 곳에 도달하지 못하는 경우가 있다고 생각한다.첫 번째 이유는 카테고리:미국의 교육→카테고리:미국에 기반을 둔 교육 조직→카테고리:미국에 기반을 둔 학술단체들, 하지만 제외되려면 계층을 선택해야 한다: 카테고리:캐나다→카테고리:캐나다의 교육→카테고리:캐나다에 기반을 둔 교육 조직→카테고리:캐나다에 기반을 둔 학술 단체.두 척의 배라면 5단 깊이로 들어가야 할 것 같은데, 그렇게 되면 상당한 누수가 시작될 수도 있다.크립틱, 배제의 깊이를 4페이지나 5페이지로 늘리면 리스트에 몇페이지가 있을지 알아?{{u Sdkb}}} 18:06, 2021년 10월 19일 (UTC)[응답]

아, 그리고 카테고리 아래 기사도 제외해야 할 것 같아.WP당 미국의 군사:MILFORMAT. {{u Sdkb}} 18:57, 2021년 10월 19일 (UTC)[응답]

캐나다 및 미국 언어 협회에 대한 귀하의 카운트는 옳지만("for"가 "four"의 오타인 경우), 경로가 잘못됨 - 범주:캐나다의 교육은 카테고리의 직접적인 하위 요소가 아니다.Canada 및 Canada 및 Category:캐나다에 기반을 둔 학술단체는 카테고리의 직접적인 하위조직이 아니다.캐나다에 기반을 둔 교육 단체.카테고리:국가 이름을 딴 위키백과 카테고리(깊이 0) > 카테고리:캐나다 (깊이 1) > 카테고리:캐나다에 기반을 둔 단체 (심층 2) > 카테고리:주제별 캐나다에 기반을 둔 단체 (심층 3) > 카테고리:캐나다에 기반을 둔 학술 단체 (심층 4)

범주의 깊이:미국의 군사?(그 범주에 있는 기사만 깊이 0이고, 직접 하위캣 범주에 있는 기사만 해당됨:미국의 군사 항공은 우리가 같은 얘기를 하고 있다는 것을 확신하는 깊이 1등이다.)

카테고리의 4개 하위 캐트에 있는 문서를 제외한 쿼리:국가 이름을 딴 위키백과 카테고리는 죽을 것 같다. 그다지 놀랍지 않다. 범주 4의 깊이:미국은 8165개 범주로, 3개 범주의 깊이:국가 이름을 딴 위키백과 카테고리는 39249이고, 그 중 깊이 4는 166700이다. —Cryptic 21:24, 2021년 10월 19일 (UTC) 물론 내가 편집 내용을 포기하고 저장한 직후 완료되었다 - 172888 결과, 군사 하위 계수를 사용하지 않은 채 깊이 4:172888; 캐나다 언어 협회 및 미국 및 캐나다 영연방을 위한 미국 및 당이 정확히 제외된 상태, 프랑스 선박 기사는 그대로 남아 있다.—크립틱 21:29, 2021년 10월 19일 (UTC)[응답]

(갈등을 편집한다) 미군에게는 3의 깊이가 너무 많은 누설을 일으키지 않고 바라건대 그 영역에 있는 모든 기사들을 캡처할 수 있을 것이라고 말하고 싶다.그리고 별로 놀랍지도 않다; 그것은 많은 카테고리가 있다. 하하.우리가 100%에 도달할 수 있을지 의문이지만, 나는 우리가 꽤 가까워졌다고 생각한다.{{u Sdkb}}^talk 21:33, 2021년 10월 19일 (UTC)[응답]

162590년 기사.리스트를 우편으로 보냈어.—크립틱 22:11, 2021년 10월 19일 (UTC)[응답]

정말 고마워!{{u Sdkb}} 18:38, 2021년 10월 20일 (UTC)[응답]

메인 스페이스의 링크가 있는 초안 PAGENAME이 존재하지 않음

안녕, 두 가지 관련 질의를 찾고 있는데 하나는 카운트하고 다른 하나는 샘플 페이지야

• 카운트 – 초안 공간에 얼마나 많은 존재하지 않는 페이지가 메인 스페이스에서 하나 이상의 인링크를 가지고 있는가? (즉, 초안인 경우:Foo_123에는 메인 스페이스에서 인링크(In-link)가 한 개 있는데, 초안:bar_456은 5개, 초안:Baz_678은 100개, 총계수는 3개)
• 샘플 – 해당 세트에서 다소 무작위로 선택된(즉, 'A'로 시작하는 모든 PAGENAMEs) 약 12개 또는 2개의 존재하지 않는 PAGENAME 목록을 얻을 수 있는가?

추가 마일리지: 링크 내 메인스페이스 수가 가장 많은 빨간색 Migritspace 페이지 이름은 무엇이며 몇 개인가?고마워!매트릭스글롯(토크) 06:02, 2021년 10월 25일 (UTC)[응답]

메인 스페이스에서 드래프트까지의 모든 링크(가능성이 있는 {{R이 만든 71000개 이상의 자극적인 가짜는 제외)는 채석장:query/59495에 있다.둘 이상의 링크가 연결된 유일한 링크는 드래프트:2021 풋볼 퀸즐랜드 프리미어리그뿐이다.—크립틱 14:13, 2021년 10월 25일 (UTC)[응답]

@Crypic:, Super, 정말 고마워!매트릭스글롯 (토크) 02:58, 2021년 10월 26일 (UTC)[응답]

동일한 템플릿에 동일한 저널/매거진/작업/웹사이트/뉴스페이퍼= 및 게시자=를 가진 기사 목록

기본적으로, 나는 이런 것들을 찾고 있다.

• {{cite journal ... journal=Foobar publisher=Foobar}}
• {{cite magazine... magazine=Foobar publisher=Foobar}}
• {{cite journal ... work=Foobar publisher=Foobar}}
• {{cite web ... website=Foobar publisher=Foobar}}
• {{cite news... newspaper=Foobar publisher=Foobar}}
• {{citation ... journal=Foobar publisher=Foobar}}

예: 템플릿에 [] 중 하나가 있는 경우 journal=, magazine=, work=, website=, newspaper=A와 일치하는 ] publisher=같은 견본이라면 알고 싶겠지.공백과 케이싱이 다르더라도 괜찮아.고마워요.헤드폭탄 {t · c · p · b} 00:51, 2021년 10월 17일 (UTC)[응답]

이것은 질의할 수 있는 것이 아니다.다른 페이지로 분류하거나 링크하는 등의 부작용이 없는 한 템플릿의 전횡은 볼 수 있지만 그들의 주장은 볼 수 없다(예를 들어 저널=Foobar 출판사=Foobar 둘 다 기사를 Foobar로 연결하도록 만든 경우, 우리는 반복을 볼 수 없었다.

나는 이것들을 찾는 유일한 실용적인 방법은 모듈을 만드는 것이라고 생각한다.인용/CS1은 그러한 일치에 대한 추적 범주를 내보낸다.모듈 토크에서 다음 사항을 물어 보십시오.인용/CS1/특징 요청?—크립틱 22:27, 2021년 10월 18일 (UTC)[응답]

음.. 그건 좀 구려.그래, 다른 방법을 생각해 봐야겠다.헤드폭탄 {t · c · p · b} 23:14, 2021년 10월 18일 (UTC)[응답]

이미 알고 있을 테지만, 오하이퍼시언스의 <소스>에는 그런 것들을 타겟으로 할 수 있는 대본이 몇 개 있다.새벽시커2000 09:27, 2021년 10월 28일 (UTC)[응답]

@Dawnseeker2000:이것에서 벗어난 것은 아니지만, 당신은 링크를 가지고 있는가?헤드폭탄 {t · c · p · b} 22:33, 2021년 10월 30일 (UTC)[응답]

예, 사용자:Ohconfucius/script/Source.js, line 194–199 및 430–433.새벽시커2000 23:03, 2021년 10월 30일 (UTC)[응답]

수정기호 테이블을 통해 요약 텍스트 편집 검색

그래서 어젯밤 나는 다소 흥미로운 편집 요약 패턴으로 이 IP 범위를 발견했고, 제한된 MySQL 지식을 사용하여 데이터베이스 쿼리를 사용하여 더 많은 인스턴스를 검색하는 방법을 알아낼 수 있을 것이라고 생각했다.쿼리 24762를 사용하여 서드체인즈 테이블의 작업 질의를 했지만, 그것을 전체 수정 테이블에 적용하려는 나의 시도는 눈부시게 실패했다(그것은 걸려 있는 것 같다(지금 약 12시간 정도 실행되고 있다) 그러나 어떻게 막을 수 있을지는 알 수 없다.나는 원래 "%https://en.wikipedia.org/wiki/American_and_British_English_spelling_differences#/media/File:Defence_Defence_Defence_Defence_Labour_Labour_Labour_Labour_American_spelling_by_country.svg%"라는 문구를 검색해 보았지만, mediawiki.org의 이 스레드는 이와 같은 접두사 검색이 믿을 수 없을 정도로 느려서 쿼리 문자열을 "중으로 바꾸었다." 철자율" 및 쿼리를 성공 없이 최대한 단순화했다.이 경우에는 "revision_comment"의 대안적 관점을 어떻게 활용할 수 있는지 알 수 없다.내가 한 최근 Changes 테스트와 IP 범위에 대한 다른 독립적인 검색으로 판단하건대, 더 많은 결과가 있을지는 잘 모르겠지만, 수정 표에 있는 이 정보에 대해 성공적인 질의를 할 수 있도록 도와줄 수 있는 사람이 있다면 고맙다.Graham87 08:31, 2021년 11월 7일 (UTC)[응답]

자, 5가지 문제부터 시작해보자.

1. 코멘트에 대한 가입 조건의 첫 번째 부분("ON comment_id = comment.comment_id")은 tautological이다."ON comment_id = rev_comment_id"를 원하는 경우.
2. 수정본과 페이지 사이의 결합을 정의해야 하는 경우 - 명시적으로("FROM revision JOIN 페이지 ON_id = rev_page") 또는 위치 절("WHERE /*...)을 정의하십시오.*/ AND page_id = rev_page") - 또는 이 두 테이블의 크기를 함께 곱한 테이블과 동일한, 약 70조 개의 행에 대해 쿼리할 수 있다.
3. 개정표는 10억 행이 넘는다.검색할 행과 rev_comment_id가 인덱싱되지 않은 행을 제한하는 일부(인덱싱된) 방법이 없다면, comment.comment.comment_text도 인덱싱되지 않으며, 쿼리가 완료에 근접할 수도 없다.rev_messages는 최근 변경 사항 질의에서 rc_messages와 같이 첫 번째 단계로, 충분히 좁다면 actor_name에 부분 매치하는 것도 도움이 될 수 있다.
4. 그리고 당신이 찾고 있는 대체적인 견해는 comment_revision이지 revision이지 수정_comment는 아니다, 비록 #3에 비추어 볼 때, 단순히 코멘트를 사용하는 것에 비해 눈에 띄는 차이는 없을 것이다.
5. comment.comment_text는 어차피 인덱싱되지 않기 때문에 접두사 와일드카드 검색을 피하는 것은 문제가 되지 않을 것이다.—크립틱 09:20, 2021년 11월 7일 (UTC)[응답]

결과가 2021년으로 제한된 예는 채석장:query/59765이다.한 번에 1, 2년 정도는 할 수 있을 겁니다. 상대적으로 적은 수의 경기(최대 몇 천 명)만 기대하면 채석리가 질식하지 않을 겁니다.—크립틱 10:28, 2021년 11월 7일 (UTC)[응답]

정말 고마워!나는 최근에야 너의 두번째 메세지를 알아챘고 너의 조언과 내가 만든 다른 실험들을 사용했어. 그것도 잘 된 것 같아.URL을 검색하면 "미국 철자 사용" 검색과 다른 결과가 나오기도 한다.나는 너의 질문으로 59770을 만들었다.저 녀석은 잠시 뛰어가게 놔둘게.Graham87 13:37, 2021년 11월 7일 (UTC)[응답]

전기 페이지가 기회를 리디렉션함

이 아이디어와 관련하여, 예를 들어, 여러 리디렉션을 만들고 싶다.Jane Lastname to Jane Q. 성씨.다음 기준에 맞는 기사 목록을 작성할 수 있을까?

1. 카테고리의 하위 카테고리에서:사람(또는 {{Wiki Project Electric}} 태그가 붙은 토크 페이지, 그게 더 쉽다면)
2. 제목이 형식이다.[word1] [capitalletter]. [word2]
3. 제목이 붙은 기사는 없다.[word1] [word2], 그리고 제목이 있는 다른 기사들[word1] [anything] [word2]

건배, {{u Sdkb}} 22:24, 2021년 11월 21일 (UTC)[응답]

사실상 어떤 것이든 카테고리 트리를 쿼리하는 것보다 쉽다.

"A"로 시작하는 히트곡에 대한 쿼리:쿼리/60063.이것을 한 번에 일정한 초기 문자로 제한하면 1회당 약 6분에서 1회당 1초 반 정도로 쿼리를 훨씬, 훨씬 더 빠르게 만든다.—크립틱 01:45, 2021년 11월 22일 (UTC)[응답]

리디렉션이 존재하지 않을 때 독자가 "제인 성"을 검색하면 어떻게 되는가?제인 큐라는 기사를 보면 검색 결과를 알 수 있을 겁니다 성이 제목과 일치하면 검색 결과의 맨 위에 나타난다.자, 만약 어느 시점에서 제인 R에 대한 기사가 만들어지면 어떻게 될까? 성?리디렉션이 생성되지 않은 경우, 두 문서 모두 검색 결과에서 접근할 수 있는 상태로 남아 있을 것이다.그러나 리디렉션이 생성되었다면, 두 기사 중 오직 한 기사만 접근할 수 있을 것이다.

미래를 들여다보지 않더라도 제인 라스트네임(뮤지션)에 대한 기사도 있다면 지금 무슨 일이 일어날까.아니면 현재 J.K. Last name이라고 이름 붙여진 또 다른 Jane Lastname에 대해서?– 우안팔라 (대화) 02:09, 2021년 11월 22일 (UTC)[응답]

@uanfala, ack, 나는 디스어셈블리에 대해 잊었다. 그것을 제기해줘서 고마워.@Cryptic, 채석장이 저것을 커버하는가, 아니면 조정이 필요한가?J.K. 라스트네임 예에 대해 우리가 합리적으로 할 수 있는 일이 있을지는 모르겠지만, 그건 꽤 드문 상황인 것 같다.

향후 기사의 가능성과 관련하여, 백과사전에 통합하기 위해 기사를 작성하는 사람은 누구라도 책임져야 한다는 것이 나의 생각이다.그래서 누가 제인 R을 만들었든지 간에성인은 제인 큐에게 해트노트를 붙여야 한다.성(그녀가 주요 주제인 경우) 또는 제인 성(제인 성)을 설명 페이지(그렇지 않은 경우)로 변환한다.베스트, {{u Sdkb}}^talk 02:38, 2021년 11월 22일 (UTC)[응답]

'제인 라스트네임'에서 '제인 큐'까지 내비게이션을 만든 것은 크리에이터(또는 큐레이터)의 책임이었는지도 모른다.성" 그러나 여러분이 여기 있다는 사실과 여러분의 질문이 수천 개의 결과에 대해 수천 개의 결과를 돌려준다는 사실은 그 사람들이 신뢰할 수 없다는 것을 분명히 보여준다.나는 당신의 사업에 동의하지만, 이러한 유형의 새로 만들어진 기사들을 추적하고 필요에 따라 혼란스럽게 하는 강력한 시스템이 존재해야만 장기적으로 순긍정이 될 것이다.– 우안팔라 (대화) 03:06, 2021년 11월 22일 (UTC)[응답]

독자들이 길을 찾는 것을 돕는 것 외에도, 내가 이것과 함께 방지하고자 하는 상황은 누군가가 제인 라스트네임을 재연결하고, 누군가 나중에 제인 큐를 창조하는 것이다. 리디렉션되지 않은 성씨, 그리고 나서 제3자가 레드링크를 클릭해서 기사로 바꾸려고 하는데, 이미 존재하는 것을 깨닫지 못한다.나는 그런 일이 일어나거나 거의 일어나는 것을 몇 번 본 적이 있어, 그래서 나는 그게 더 큰 문제로 보여.{{u Sdkb}}} 20:53, 2021년 11월 22일 (UTC)[응답]

그것은 타이틀과 디스암비게이터를 비교하지 않을 것이다; 그것은 타이틀의 끝에서 특별히 단어 2를 찾는다.그렇게 만들 수는 있지만, 사실 제목에서 어느 곳에서나 성씨를 찾도록 하는 것이 더 쉽기 때문에 제인 Q. 성명은 오스트리아 제인 라스트네임(Jane Lastname)에 의해 금지될 것이다.—크립틱 10:20, 2021년 11월 22일 (UTC)[응답]

매일 자동 생성되는 기사 수

나는 이것에 대한 질의 초안을 작성했지만 몇 가지 문제에 부딪쳤다.너희가 고칠 수 있는지 좀 봐줄래?가명을 쓰려고 하는데day 마음에 안 드는 부분이 있어서 어떻게 고쳐야 할지 모르겠어고마워요.–Novm Languageae(대화) 02:18, 2021년 12월 13일 (UTC)[응답]

카운트(*)를 하고 주문 기준 앞에 조항에 따라 그룹을 배치하십시오.—크립틱 02:22, 2021년 12월 13일 (UTC)[응답]

잘됐네, 고마워두 번째 문제.왜 이 질의가 1년치 자료만 돌려주는 것일까?pagetregations_log 테이블에 오래된 항목이 삭제되거나 다른 항목이 있는 경우–Novm Languageae(대화) 02:27, 2021년 12월 13일 (UTC)[응답]

그런 것 같아. "SELECT ptrl_timestamp FROM pagetregations_log ORDER BY ptrl_timestamp ASC Limit 1"은 나에게 20201212205515를 준다.—크립틱 02:31, 2021년 12월 13일 (UTC)[응답]

기사작성자 목록

나는 기사의 작가를 얻는 질의를 썼다.여러 기사의 저자들을 한 질의에 끌어들이기 위해 이것을 얻기를 원했다면, 그것을 리팩터링하는 가장 좋은 방법은 무엇일까?왜? 서브쿼리?여기 나의 페이지 ID 목록이다.감사합니다. 66411662, 63051276, 67331300, 67494602, 67251604, 67475738, 67025524, 67282385, 67492243, 67505824, 68570713, 65754113, 68673796, 67481281, 68288689, 67485694, 68624634, 67062564, 67486327, 65912571, 67495969, 65558215, 67162967, 67504737, 66978220, 65952291, 67306801, 64208962, 67222236, 67365517, 68510913, 67480539, 66411751, 65228882, 67252944, 66476730, 68469744, 67008083, 66555751, 67282708, 67419043, 68693806 –Novm Languageae(대화) 16:57, 2021년 12월 27일(UTC)[응답]

Rather than fetching all revisions for a given page and showing only the lowest, I'd get a list of rev_id's with a subquery (SELECT MIN(rev_id) FROM revision WHERE rev_page IN (66411662, 63051276, /* etc etc */) GROUP BY rev_page) then select page_namespace, page_title, actor_name for each of those.—크립틱 17:11, 2021년 12월 27일 (UTC)[응답]

쿼리가 고착

몇 개의 고정된 질문(61115, 58635)이 있는데, 이 질문들은 여전히 내가 설정한 max_statement_time을 초과하여 실행된다고 주장한다.테이블이 크다는 것은 알고 있지만, 나는 생계를 위해 SQL을 쓰곤 했던 경험이 풍부한 Quarry 사용자인데, Optimizer는 쿼리가 기대지수를 효율적으로 사용한다고 제안한다.Stop(중지) 버튼은 HTML 500 응답을 반환하고 아무것도 하지 않는 것 같다.이 SQL들은 사실상 죽은 것인가, 아니면 그것들을 방출하기 위한 일종의 정기적인 정화 과정이 있는가?나는 서버에 과부하가 걸릴 경우를 대비해서 그것들을 포장하거나 내 일을 반복하는 것을 꺼린다.예전에는 어떤 이유로 (기억이 부족합니까?) 죽은 후 실행한다고 주장했던 쿼리가 기억나지만, 그러한 경우에는 쿼리가 영구적으로 "실행"으로 잠겨 있기 보다는 수정하여 다시 실행할 수 있었다.Certes (talk) 00:29, 2021년 12월 31일 (UTC)[응답]

SQL에 대해서는 전혀 모르지만, 중지 버튼이 작동하지 않는 것(c의 경우는 당신이 설명하고 있는 것의 한 측면일 뿐)은 알려진 이슈인 https://phabricator.wikimedia.org/T290146으로 나타난다.– 우안팔라 (대화) 01:12, 2022년 1월 4일 (UTC)[응답]

나는 일련의 큰 Cirrus 검색을 상호 연관시켜 그 작업을 덜 효율적으로 완료했지만, 여전히 어떤 응답에도 관심이 있을 것이다.인증서 (대화) 20:47, 2022년 1월 5일 (UTC)[응답]

프로젝트 리디렉션 누락

모든 위키에서 파일 쿼리

여보세요!

MIME 유형이 있는 모든 파일을 쿼리하십시오.image/x-bmp그리고image-x-xcf, 각각 모든 위키(Wikipedia, Commons, Wikibooks, Mediawiki 등의 모든 언어 버전)에 걸쳐.모두 Special:에서 찾을 수 있다.MIMESearch/image/x-bmp 및 Special:각 wiki(또는 Special:검색/파일:로컬: filemime:bmp / 특수:검색/파일:로컬: filemime:xcf).위키링크가 위키에서 작동하도록 리스트를 이렇게 렌더링했으면 한다.

w:File.NAME.bmp
fr:파일.NAME.bmp
c:파일:NAME.bmp
pt:v:파일:NAME.bmp
등

가능할까요?명확히 하기 위해 MIME 유형당 한 개씩 두 개의 쿼리를 원한다.고마워!존테밀 (대화) 21:28, 2022년 1월 9일 (UTC)[응답]

Wiki가 서로 다른 데이터베이스 서버에 있기 때문에 지금은 가능하지 않다(그리고 이전에는 결코 쉽지 않았다.할 수 있는 최선의 방법은 하나의 위키에서 쿼리를 실행하는 방법을 보여주는 것이고, 각 위키에서 쿼리를 실행할 수 있도록 하는 것이다.—크립틱 21:44, 2022년 1월 9일 (UTC)[응답]

@Cryptic:그렇구나, 답장 고마워.특별 이후:MIMESearch는 모든 위키에서 작업을 할 것이다. 그것은 질문할 필요가 없다.쿼리를 요청한 이유는 모든 위키에서 모든 BMP와 XCF 파일에 대해 컴파일된 목록을 작성하기 위해서였을 뿐이지만, 나는 그것이 불가능하다고 생각한다.존테밀 (대화) 22:49, 2022년 1월 9일 (UTC)[응답]