사전 요약:
회사에서 운영하는 쇼핑몰 시스템에서 갑자기 주문 철회 기능에 문제가 있다는 사실을 발견했습니다. 많은 가맹점에서 주문 금액과 일치하지 않는다는 신고가 접수되었습니다. 그래서 수요가 발생하여 출금테이블과 공급업체 테이블을 결과세트로 활용하고, 주문테이블의 주문금액을 연결하고, 주문테이블의 금액과 반영테이블의 가맹점이 출금한 금액을 비교해야 했습니다. 판매자가 더 많은 돈을 인출했는지 확인합니다.
내 쿼리 과정이 아래에 기록되어 있습니다.
조회 과정:
처음에는 첫 번째 단계에서 출금 테이블을 메인 테이블로 사용하여 관련 결과를 쿼리했습니다. MySQL 문은 다음과 같습니다
SELECT count(ysw.supply_id) AS '提现次数',ysw.user_id AS '供应商对应的用户ID', ysw.supply_id AS '供应商ID' ,SUM(ysw.money) AS '供应商提现总金额', case ysw.pay_type when 10 then '微信' when 20 then '支付宝' else '银行卡' end as '支付方式' , ys.supply_name AS '供应商名称',ys.money AS '供应商余额',ys.freez_money AS '供应商冻结金额(已提现金额)' FROM yoshop_supply_withdraw AS ysw LEFT JOIN yoshop_supply AS ys ON ysw.supply_id = ys.supply_id WHERE ysw.create_time < 1647446400 AND ysw.apply_status IN (10,20,40) GROUP BY ysw.supply_id ORDER BY SUM(ysw.money) DESC ;
쿼리 결과는 다음과 같이 정상입니다.
다음으로 왼쪽 링크의 주문 테이블 데이터에 왼쪽 조인을 추가했는데 금액 관련 데이터가 변경되어 심각하게 불일치했습니다. 그리고 쿼리 시간은 당연히 연장되었고, MySQL 문은 다음과 같습니다
SELECT count(ysw.supply_id) AS '提现次数',ysw.user_id AS '供应商对应的用户ID', ysw.supply_id AS '供应商ID' ,SUM(ysw.money) AS '供应商提现总金额', case ysw.pay_type when 10 then '微信' when 20 then '支付宝' else '银行卡' end as '支付方式' , ys.supply_name AS '供应商名称',ys.money AS '供应商余额',ys.freez_money AS '供应商冻结金额(已提现金额)',SUM(yo.pay_price) FROM yoshop_supply_withdraw AS ysw LEFT JOIN yoshop_supply AS ys ON ysw.supply_id = ys.supply_id LEFT JOIN yoshop_order AS yo ON yo.supply_ids =ysw.supply_id WHERE ysw.create_time < 1647446400 AND ysw.apply_status IN (10,20,40) GROUP BY ysw.supply_id ORDER BY SUM(ysw.money) DESC ;
쿼리 결과 비교 차트는 다음과 같습니다.
실습 후, 직접 출금 테이블 금액과 주문 테이블 금액을 통해 쿼리하고 싶습니다. 왼쪽 조인은 가능하지 않습니다. 온라인으로 정보를 확인하고 기술 그룹에 조언을 요청하여
아이디어를 최적화했습니다. 현금 인출에 대한 좋은 통계를 만들고, 주문에 대한 좋은 통계를 만들고, 마지막 두 결과 세트에 대해 공급업체 ID를 기반으로 링크를 만듭니다
The 다음 단계는 3단계입니다. 첫 번째 단계: 출금 통계를 수집합니다. 위 시도의 첫 번째 단계는 두 번째 단계: 주문 테이블의 데이터를 수집하는 것입니다. 시스템 사용으로 인해 주문 상품 테이블을 직접 사용하여 총 주문 금액을 계산합니다. 이 단계도 3단계로 나누어져 있습니다. 코드를 직접 입력합니다:
1.查询yoshop_order所有进行中,已完成的 订单id(order_id); SELECT order_id FROM yoshop_order WHERE order_status IN (10,30); 2.查询没有退款的订单ID SELECT order_id FROM yoshop_order WHERE order_status IN (10,30) AND order_id NOT IN ( SELECT order_id FROM yoshop_order_refund); 3.查询订单商品表中 所有的订单金额 SELECT supply_id AS '供应商ID' , SUM(total_pay_price) AS '供应商订单总金额' FROM yoshop_order_goods WHERE create_time < 1647446400 AND order_pay_status = 0 AND order_id IN(SELECT order_id FROM yoshop_order WHERE order_status IN (10,30) AND order_id NOT IN ( SELECT order_id FROM yoshop_order_refund) ) GROUP BY supply_id ORDER BY SUM(total_pay_price) DESC ;
다음 단계는 첫 번째와 두 번째를 쿼리하는 것입니다. 결과는 왼쪽 조인 쿼리에 대한 파생 테이블로 사용됩니다. 제가 가장 많은 시간과 에너지를 소비하는 단계입니다. 잘 읽어보시면 받아보실 거라 믿습니다. 여기에 잘못된 프로세스도 기록했습니다. 첫 번째 잘못된 접합:
SELECT * FROM ( SELECT count(ysw.supply_id) AS '提现次数',ysw.user_id AS '供应商对应的用户ID', ysw.supply_id AS 'supply_id' ,SUM(ysw.money) AS '供应商提现总金额', case ysw.pay_type when 10 then '微信' when 20 then '支付宝' else '银行卡' end as '支付方式' , ys.supply_name AS '供应商名称',ys.money AS '供应商余额',ys.freez_money AS '供应商冻结金额(已提现金额)' FROM yoshop_supply_withdraw AS ysw LEFT JOIN yoshop_supply AS ys ON ysw.supply_id = ys.supply_id WHERE ysw.create_time < 1647446400 AND ysw.apply_status IN (10,20,40) GROUP BY ysw.supply_id ORDER BY SUM(ysw.money) DESC ) AS t1 union all // left join ,这里是注释记得删除 SELECT * FROM -- 这里是错误的不应该在查询 (SELECT supply_id AS 'supply_id' , SUM(total_pay_price) AS total_pay_price FROM yoshop_order_goods WHERE create_time < 1647446400 AND order_pay_status = 0 AND order_id IN( SELECT order_id FROM yoshop_order WHERE order_status IN (10,30) AND order_id NOT IN ( SELECT order_id FROM yoshop_order_refund) ) GROUP BY supply_id ORDER BY SUM(total_pay_price) DESC ) AS t2 ON t1.suppply_id = t2.suppply_id
이번 시행착오를 통해 제가 left Join 및 Union all의 의미를 잘못 기억하고 접합 중에 이를 재사용했다는 것이 분명해졌습니다. 시행착오였지만 상품을 받았고 두 번째 잘못된 접합이 이루어졌습니다.
SELECT t1.提现次数 ,t1.供应商对应的用户ID ,t1.supply_id, t1.支付方式 ,t1.供应商名称,t1.供应商余额, t1.供应商冻结金额(已提现金额), t2.total_pay_price FROM ( SELECT count(ysw.supply_id) AS '提现次数',ysw.user_id AS '供应商对应的用户ID', ysw.supply_id AS supply_id ,SUM(ysw.money) AS '供应商提现总金额', case ysw.pay_type when 10 then '微信' when 20 then '支付宝' else '银行卡' end as '支付方式' , ys.supply_name AS '供应商名称',ys.money AS '供应商余额',ys.freez_money AS '供应商冻结金额(已提现金额)' FROM yoshop_supply_withdraw AS ysw LEFT JOIN yoshop_supply AS ys ON ysw.supply_id = ys.supply_id WHERE ysw.create_time < 1647446400 AND ysw.apply_status IN (10,20,40) GROUP BY ysw.supply_id ORDER BY SUM(ysw.money) DESC ) AS t1 LEFT JOIN (SELECT supply_id AS supply_id , SUM(total_pay_price) AS total_pay_price FROM yoshop_order_goods WHERE create_time < 1647446400 AND order_pay_status = 0 AND order_id IN( SELECT order_id FROM yoshop_order WHERE order_status IN (10,30) AND order_id NOT IN ( SELECT order_id FROM yoshop_order_refund) ) GROUP BY supply_id ORDER BY SUM(total_pay_price) DESC ) AS t2 ON t1.suppply_id = t2.suppply_id
이 두 번의 잘못된 시도를 통해, 시도 중 MySQL에서 제공한 오류 프롬프트를 기반으로 나는 내가 나라는 것을 알았습니다. 왼쪽 조인을 사용하는 데 실수가 있었습니다. 처음에 모든 필드를 쿼리해야 합니다. 왼쪽 조인 후에는 select *를 사용할 수 없습니다. 마지막으로 배운 왼쪽 조인 구문을 기억하고 최종 올바른 쿼리 결과를 작성했습니다. 결과 스크린샷:
위 내용은 MySQL 파생 테이블 조인 테이블 쿼리 분석 예의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

MySQL은 GPL 라이센스를 사용합니다. 1) GPL 라이센스는 MySQL의 무료 사용, 수정 및 분포를 허용하지만 수정 된 분포는 GPL을 준수해야합니다. 2) 상업용 라이센스는 공개 수정을 피할 수 있으며 기밀이 필요한 상업용 응용 프로그램에 적합합니다.

MyISAM 대신 InnoDB를 선택할 때의 상황에는 다음이 포함됩니다. 1) 거래 지원, 2) 높은 동시성 환경, 3) 높은 데이터 일관성; 반대로, MyISAM을 선택할 때의 상황에는 다음이 포함됩니다. 1) 주로 읽기 작업, 2) 거래 지원이 필요하지 않습니다. InnoDB는 전자 상거래 플랫폼과 같은 높은 데이터 일관성 및 트랜잭션 처리가 필요한 응용 프로그램에 적합하지만 MyISAM은 블로그 시스템과 같은 읽기 집약적 및 트랜잭션이없는 애플리케이션에 적합합니다.

MySQL에서 외국 키의 기능은 테이블 간의 관계를 설정하고 데이터의 일관성과 무결성을 보장하는 것입니다. 외국 키는 참조 무결성 검사 및 계단식 작업을 통해 데이터의 효과를 유지합니다. 성능 최적화에주의를 기울이고 사용할 때 일반적인 오류를 피하십시오.

MySQL에는 B-Tree Index, Hash Index, Full-Text Index 및 공간 인덱스의 네 가지 주요 인덱스 유형이 있습니다. 1.B- 트리 색인은 범위 쿼리, 정렬 및 그룹화에 적합하며 직원 테이블의 이름 열에서 생성에 적합합니다. 2. HASH 인덱스는 동등한 쿼리에 적합하며 메모리 저장 엔진의 HASH_Table 테이블의 ID 열에서 생성에 적합합니다. 3. 전체 텍스트 색인은 기사 테이블의 내용 열에서 생성에 적합한 텍스트 검색에 사용됩니다. 4. 공간 지수는 지리 공간 쿼리에 사용되며 위치 테이블의 Geom 열에서 생성에 적합합니다.

toreateanindexinmysql, usethecreateindexstatement.1) forasinglecolumn, "createindexidx_lastnameonemployees (lastname);"2) foracompositeIndex를 사용하고 "createDexIdx_nameonemployees (forstName, FirstName);"3)을 사용하십시오

MySQL과 Sqlite의 주요 차이점은 설계 개념 및 사용 시나리오입니다. 1. MySQL은 대규모 응용 프로그램 및 엔터프라이즈 수준의 솔루션에 적합하며 고성능 및 동시성을 지원합니다. 2. SQLITE는 모바일 애플리케이션 및 데스크탑 소프트웨어에 적합하며 가볍고 내부질이 쉽습니다.

MySQL의 인덱스는 데이터 검색 속도를 높이는 데 사용되는 데이터베이스 테이블에서 하나 이상의 열의 주문 구조입니다. 1) 인덱스는 스캔 한 데이터의 양을 줄임으로써 쿼리 속도를 향상시킵니다. 2) B-Tree Index는 균형 잡힌 트리 구조를 사용하여 범위 쿼리 및 정렬에 적합합니다. 3) CreateIndex 문을 사용하여 CreateIndexIdx_customer_idonorders (customer_id)와 같은 인덱스를 작성하십시오. 4) Composite Indexes는 CreateIndexIdx_customer_orderOders (Customer_id, Order_Date)와 같은 다중 열 쿼리를 최적화 할 수 있습니다. 5) 설명을 사용하여 쿼리 계획을 분석하고 피하십시오

MySQL에서 트랜잭션을 사용하면 데이터 일관성이 보장됩니다. 1) STARTTRANSACTION을 통해 트랜잭션을 시작한 다음 SQL 작업을 실행하고 커밋 또는 롤백으로 제출하십시오. 2) SavePoint를 사용하여 부분 롤백을 허용하는 저장 지점을 설정하십시오. 3) 성능 최적화 제안에는 트랜잭션 시간 단축, 대규모 쿼리 방지 및 격리 수준을 합리적으로 사용하는 것이 포함됩니다.


핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

Video Face Swap
완전히 무료인 AI 얼굴 교환 도구를 사용하여 모든 비디오의 얼굴을 쉽게 바꾸세요!

인기 기사

뜨거운 도구

WebStorm Mac 버전
유용한 JavaScript 개발 도구

DVWA
DVWA(Damn Vulnerable Web App)는 매우 취약한 PHP/MySQL 웹 애플리케이션입니다. 주요 목표는 보안 전문가가 법적 환경에서 자신의 기술과 도구를 테스트하고, 웹 개발자가 웹 응용 프로그램 보안 프로세스를 더 잘 이해할 수 있도록 돕고, 교사/학생이 교실 환경 웹 응용 프로그램에서 가르치고 배울 수 있도록 돕는 것입니다. 보안. DVWA의 목표는 다양한 난이도의 간단하고 간단한 인터페이스를 통해 가장 일반적인 웹 취약점 중 일부를 연습하는 것입니다. 이 소프트웨어는

SublimeText3 영어 버전
권장 사항: Win 버전, 코드 프롬프트 지원!

에디트플러스 중국어 크랙 버전
작은 크기, 구문 강조, 코드 프롬프트 기능을 지원하지 않음

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기
